Re: If merging that is really fast forwarding creates new commit

Liu Yubao <yubao.liu@gmail.com> writes:

So you want to see list of commits that happened to be at the tip of my 'master' branch. I would not say that view does not exist, but it is probably not very useful. And the uselessness of it depends majorly on the reason why you say "I don't care how this feature is realized" in the above picture. Care to elaborate why not?

side note: I do not merge next to master so "from next" above in reality would be "from a topic branch" or "from maint", but it is otherwise a good example.

What appeared in 'master' recently are three kinds of changes:

 - Many fixes that still apply to 1.4.3 codebase were sent from
   the list (thanks, everybody!), which were applied to 'maint',
   and merged into 'master'.

 - Some other obviously correct fixes and changes that address
   issues on features added after the 1.4.3 release (hence
   missing from 1.4.3 codebase and 'maint' but in 'master') were
   applied directly on 'master'.

 - Yet some other fixes and changes that concern post-1.4.3
   codebase (i.e. 'master only' changes) were forked off of the
   tip of 'master' when the patches were received, cooked in
   their own topic branches (which were merged in 'next'), and
   then merged into 'master'.

So, we have two kinds of obviously correct changes to 'master' that come both from merges and direct applications. Things that happen to address older issues come as merges because they equally apply to 'maint' and merged into 'master', things that address newer issues are applied directly. Put it another way, things that come as merges to 'master' are also of two kinds. Obviously correct one that came through 'maint', and the ones that might have looked slightly wrong in the initial version and later perfected while in its own topic branch and then merged into 'master'.

The decision between cooking in a topic branch and immediately applying to 'master' is not based on the size but more on perceived usefulness of the change (something that is correct in the sense that it does not break the system may not deserve to be merged if it does not do useful things) and quality of the design and implementation. The size of the series obviously affect the perception by me but that is secondary.

Even when a patch is something that I should be able to judge as obviously correct when I am relaxed and sane, I might lack time and concentration to follow it fully, and instead decide to drop it into its own topic branch and later merge it into 'master' without need for much cooking. That kind of patch _could_ have (and should have) been applied directly to 'master' but comes as a merge.

Sometimes I apply a patch to 'master' and then later realize that change is needed and applicable to 'maint' as well. That is cherry-picked to 'maint', resulting in two independent commits. They _could_ have (and should have) come through a merge from 'maint' to 'master'.

So the change a patch introduces itself may not even have relevance to the difference between direct application and merge at all. In other words, the avenue a particular patch took, difference between direct application and merge, should not concern you. I hope this would illustrate why a view that tries to summarize what merges brought in and to give full description of what were applied directly does not make much sense.

By the way, there are two reasons why you cannot have my ref-logs. First of all, I do not have one on 'master' nor 'next' myself. More importantly, I rewind and rebuild these branches before pushing out (of course I have some safety valve to prevent me from rewinding beyond what I have already pushed out), and the ref-log entries for those tips that were rewound are not useful to you, and something I would rather not have people to even know about (think of it as giving me some privacy).

If you really care about the branch tip history of my repository, you can set up ref-log yourself on your remote tracking branch.

Strictly speaking, that is the history of fetches by you, not the history of merges and commits by me, but that is what matters more to you. If I pushed my changes out twice a day but you were away for two days, you would have seen the state of my repository four rounds back before you left and when you fetched from me today you would have the latest; three states in between were not something you can know. But it does not matter -- your repository did not have those three states, so not knowing exactly which commit they were would not hurt you when bisecting. "It worked before I pulled yesterday morning but now it is broken when I pulled this afternoon" would help your bisect get started, but multiple state changes between the times you fetched cannot matter.