According the documentation , when show full history with parent rewriting, the commit C is excluded, as it's TREESAME to parent commit I. The TREESAME means the commit C does not touch the foo file. So I think the commit C is an empty commit with change. [image: firefox_2022-01-17_14-32-50.png]
The log graph of foo file in my sample repository is same as the documentation mentioned above [image: TortoiseGitProc_2022-01-17_14-35-53.png] However it seems there is no clarified definition about the parent rewriting. and the command about show full history without parent rewriting is not mentioned. On Saturday, January 15, 2022 at 7:10:20 PM UTC+8 philip...@iee.email wrote: > I think " The commit c was made with empty change, git commit > --allow-empty!" isn't a correct reading of the docs. > > > https://github.com/ChuckTest/git-history-test/blob/de6543aca0c16e4740a8834f4df23894bea5d776/foo > > As noted earlier, my reading of the text is that file foo should have > changed to contain 'foo', from it's former 'asdf'. > > That said, I haven't tried too hard to cross check, and do agree that > having a reference repo would be a help. > > > On Saturday, January 15, 2022 at 10:29:39 AM UTC chuc...@gmail.com wrote: > >> Finally, I made a sample repository >> https://github.com/ChuckTest/git-history-test. >> The commit c was made with empty change, git commit --allow-empty >> And the TREESAME only consider file foo, if you do not modify the content >> of foo and make a new commit, then it's TREESAME for file foo. >> >> >> The default mode with command "git log --decorate --oneline --graph foo" >> full history with command "git log --decorate --oneline --graph >> --full-history foo" >> >> The question would be which command to show "--full-history without >> parent rewriting", have no idea which command can do this. >> >> On Friday, January 14, 2022 at 7:36:23 PM UTC+8 philip...@iee.email wrote: >> >>> The text itself is at >>> https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425, >>> >>> should you wish to try making it clearer. >>> >>> Unfortunately, there isn't a sample repo that contains the various >>> examples that are in the documentation. There are one or two that are >>> hidden in the test suite, but this doesn't appear to be one of them. >>> >>> How would you update the documentation to make it more useful to folks >>> like yourself trying to understand what is going on? Try posting here and >>> folks can help with preparing some patches to improve things. >>> >>> Philip >>> >>> On Friday, January 14, 2022 at 9:34:12 AM UTC Konstantin Khomoutov wrote: >>> >>>> On Thu, Jan 13, 2022 at 05:57:24PM -0800, Chuck Lu wrote: >>>> >>>> >>> https://git-scm.com/docs/git-log#_history_simplification >>>> >>> As there is no change, then how can I make a commit C? >>>> >>> [image: firefox_2022-01-13_19-46-27.png] >>>> >> Commit C is to be compared to I. >>>> >> >>>> >> In `I` foo contains "asdf" >>>> >> In `C` foo contains "foo" as described under 'A' (same as B, same as >>>> C...) >>>> >> so a confusion about the english way of describing and the graphical >>>> >> expectation. >>>> >> At least that's what I'm thinking. >>>> [...] >>>> > Yes, I know that C compare with I, and the description C does not >>>> change >>>> > foo, the foo is in red color, which means the C does not change file >>>> foo. >>>> > The content in file foo should keep the same as I which is "asdf". >>>> It's >>>> > really awful to read the documentation. >>>> > Anyway, thanks for your help, I will try to reproduce a repository >>>> with >>>> > your explanation. >>>> > >>>> > Does anyone know who wrote this terrible documentation? If it is >>>> possible, >>>> > I would like to communicate with him/her directly. >>>> >>>> The docs are written by the developers theirselves (the project is run >>>> by a >>>> volunteers, and AFAIU they don't have a dedicated technical writer in >>>> the >>>> team, and never had). You can contact the devs by posting a mail to the >>>> developers' list - please be sure to read [1]. >>>> >>>> Just in case, I urge you to be constructive: since Git is a volunteer >>>> project, >>>> and a piece of F/OSS, you got it for free, have full access to its >>>> source >>>> code - which includes the sources of the docs - and, as usual in such >>>> cases, >>>> the Git devs are not under any obligation to maintain whatever level of >>>> quality >>>> of their product. Hence you cannot sensibly demand anything from them - >>>> at >>>> best, your claims will be silently dismissed; what you could - and >>>> should - >>>> do instead is to propose ways to improve the docs: usually this is made >>>> in >>>> four steps: you offer the changes, discuss them, then post the patches, >>>> then >>>> they are reviewed, which might require multiple backs-and-forths to get >>>> completed. >>>> >>>> 1. >>>> https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list >>>> >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/62568ab2-81ab-4879-bbe9-535b8b0aa58fn%40googlegroups.com.
