Hi Laurent, On 29/10/2022 15:53, Laurent Lyaudet wrote: > Hello, > > From here : > https://git-scm.com/docs/git-log#_history_simplification > I read : >> Default mode >> Simplifies the history to the simplest history explaining the final state of the tree. >> Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content) > But I am kindly questioning if the "explaining the final state of the > tree." is correct. Importantly here, we have that a commit is a "snapshot" (of the tree), not a 'diff'. Despite all attempts (often within Git) to the contrary, a commit is never 'just a diff', though it's easy to be misled. > Because I had the following case : > > If : > - commit 1 modifies some lines of file f on a branch b, > - then commit 2 modifies some of the same lines of f on master, > - and commit 3 revert commits 2, > - and then commit 4 merges b on master, > then without --show-pulls, with git log on file f you see first 3 commits only ; > and there is no way you can apply these 3 commits Here, we have that distinction between the snapshots [i.e. the tree states], and the [false] expectation that commits are [just] diffs that can be applied. > in sequence, > as depicted, and obtain the master's current state. > > When you use git log on a branch, you expect the default : > - to give you all that happened to your branch, If it was "all" the commits, it wouldn't be a simplification.. ;-) > - or to give you a list of commits that applied successively explains > the current state of the branch. If we swap that to being .. a list of commits that can be diff'd to explain..., then it may be a better statement about the simplification.. ? > I know that with trees a sequence of commits is not sufficient. > But it would be a good property of default history simplification that > your current branch state can be obtained with the first parent > subsequence of displayed commits. > > Currently, default history simplification for git log on some branch b > also gives merges of branch b on branch b2, if later on branch b2 is > merged back on branch b. > To me this merge commits are less interesting than the merge commit of > branch b2 on branch b at the end. > > I assume that the simplification of merge commits was intended for the > simple case : > - create branch b2 from branch b1 > - n commits on branch b2 > - merge branch b2 on b1 > If no modification was made on b1 during that time, I agree that the > merge commit of b2 on b1 is not interesting. > In that case, it could explicitly say it displays commits on other > parents that could have been automatically rebased. > Like : > commit hxhxhxhxhxh > date > done on branch b2 > merged on branch b1 at date, could have been automatically rebased > Message : It was a nice commit > ... > > But in the case, some common file was touched on b1 during that time, > then it should give the final merge commit. (Solution 1) > (I said touched instead of modified because of the revert.) > Or it should also simplify and remove the commit and its revert on b1. > (Solution 2) > I would prefer either Solution 1 or Solution 2 to the current default. As I understand it, the defaults are, effectively, set relative to the needs of the Linux project, for which it was designed. > Many UIs above git use default history simplification. > Github for example uses default history simplification. > And you cannot customize the commands used with options in these UIs. That sounds useful, but is in the hands of those 'forges'. > So I hope you will find that having better default is an important topic. > > Best regards, > Laurent Lyaudet There is a github repo https://github.com/ChuckTest/git-history-test.git [1] that can be used to explore the History Simplification man page example with files foo, quux and side going through all the different TREESAME dances shown in the manual. I have a side project to see if such repos that demonstrate the man page example can be brought into the main Git 'documentation'. Note that the --graph option also brings in some options as well. -- Philip [1] https://groups.google.com/g/git-users/c/n8Rj-YBUJEw/m/S-ADI3sQCAAJ
