According the notes you provided, the documentation is really a mess, maybe lacking of review when someone wrote the documentation, nobody else review it.
Actually I used both the command line of "git for widnows" and TortoiseGit to investigate the git log history. I used the command with --graph according https://stackoverflow.com/a/35075021/13338936, but I did not realized that the --graph will enable the parent rewriting. And the TortoiseGit did not support the parameter --full-history before, https://gitlab.com/tortoisegit/tortoisegit/-/issues/3728 I have no idea if there is a tool such as gitk or TortoiseGit have implemented the full history correctly, that's why I am investigating the official documentation. Thanks for your effort, it seems the full history without parent rewriting could be reproduced by command `git log --oneline --full-history foo`. I would like to continue to investigate the reset part of git log history simplification. On Wednesday, January 19, 2022 at 7:40:47 AM UTC+8 philip...@iee.email wrote: > Thanks for the test repo. some notes. > > When I looked at it using `gitk` (with options), it generally got things > right, but it looks like the gui's don't always do the simplifications. > > What I did notice was the tendency to need the --graph option to see the > history simplification. > > I do admit that history simplification is an area I hadn't studied (but > was interested in). > > Try `git log --oneline --graph --full-history -- foo` > `git log --oneline --graph --full-history --parents -- foo` > 'git log --oneline --graph -- foo` > > etc. > > I also find "rev-list, what is it doing?" to be confusing (In parts I > still am learing). > > One 'hidden in plain view' is that the revlist has an order, and it's only > when we add --graph to a log that we start to see some of the > interconnectedness. > > Some notes I made.. > "history re-writing" > > the magic example is at > > https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425 > > --graph #L1119 **note how far down the document this is! > #L1126 This enables parent rewriting, see 'History Simplification' above. > > > #L427-429 `rev-list` walks backwards through history, including or > excluding > commits based on whether `--full-history` and/or parent rewriting > (via `--parents` or `--children`) are used. > > ** that's not `--min-parents` etc that's used for `--merges` #L104-131 > > #L453-455 Parent/child relations are only visible with `--parents`, but > that does > not affect the commits selected in default mode, so we have shown the > parent lines. > > > #L472-474 Note that without parent rewriting, it is not really possible to > talk > about the parent/child relationships between the commits, so we show > them disconnected. > > %%#L457 --full-history (without parent rewriting):: %% extra () > %%#L476 --full-history (with parent (--graph) rewriting):: %% extra (), > extra (--graph) > > Summary Question: were you investigating via a GUI tool, or via the > command line? > > On Monday, January 17, 2022 at 6:39:47 AM UTC chuc...@gmail.com wrote: > >> 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/11286f4a-c961-4d12-91a0-f49e34d8691bn%40googlegroups.com.
