Maybe default Commits History Simplification could be more sensible

[Laurent Lyaudet <laurent.lyaudet@gmail.com>]

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