Maybe default Commits History Simplification could be more sensible

Maybe default Commits History Simplification could be more sensible

[Laurent Lyaudet]

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.
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 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,
- or to give you a list of commits that applied successively explains
the current state of the branch.
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.

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.
So I hope you will find that having better default is an important topic.

Best regards,
    Laurent Lyaudet

Re: Maybe default Commits History Simplification could be more sensible

[Philip Oakley]

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