Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]

[Liu Yubao <yubao.liu@gmail.com>]

Linus Torvalds wrote:
> 
> On Mon, 6 Nov 2006, Linus Torvalds wrote:
>> Besides, doing an empty commit like that ("I fast forwarded") literally 
>> doesn't add any true history information. It literally views history not 
>> as history of the _project_, but as the history of just one of the 
>> repositories. And that's wrong.
>>
>> So just get used to it. You MUST NOT do what you want to do. It's stupid.
> 
> Btw, absolutely the _only_ reason people seem to want to do this is 
> because they want to "pee in the snow" and put their mark on things. They 
> seem to want to show "_I_ did this", even if the "doing" was a total 
> no-op and they didn't actually generate any real value.

We can kick out fake commits when calculate credits, we can grep logs with
author name to see what he/she has done.

Fake commit is only for digging branch scope history, I can *outline* what has
been merged to a branch and don't care about how these good work are done on 
earth.

> 
> That's absolutely the last thing you want to encourage, especially when 
> the end result is a history that is totally unreadable and contains more 
> "junk" than actual real work. 
> 
> I'll be the first to say that "merging code" is often as important as 
> actually writing the code in the first place, and that it is important to 
> show who actually did real work to make a patch appear in a project.
> 
> In the kernel, for example, we have "sign-off" lines to show what route a 
> patch took before it was accepted, and it's very instructive to see (for 
> example) how man patches give credit to somebody like Andrew Morton for 
> passing it on versus actually writing the code himself (he has a lot of 
> authorship credit too, but it's absolutely _dwarfed_ by his importance as 
> a maintainer - and if you were to ask any random kernel developer why 
> Andrew is so important, I can pretty much guarantee that his importance is 
> very much about those "sign-offs", and not about the patches he authors).
> 
> But at the same time, when it comes to merging, because it actually 
> clutters up history a lot, we actively try to _avoid_ it. Many subsystem 
> maintainers purposefully re-generate a linear history, rebased on top of 
> my current kernel, exactly because it makes the history less "branchy", 
> and because that makes things easier to see.
> 
> So we have actually done work to _encourage_ fast-forwarding over "merge 
> with a commit", because the fast-forwarding ends up generating a much more 
> readable and understandable history. Generating a _fake_ "merge commit" 
> would be absolutely and utterly horrible. It gives fake credit for work 
> that wasn't real work, and it makes history uglier and harder to read. 
> 
> So it's a real NEGATIVE thing to have, and you should run away from it as 
> fast as humanly possible.
> 
> Now, the kernel actually ends up being fairly branchy anyway, but that's 
> simply because we actually have a lot of real parallel development (I bet 
> more than almost any other project out there - we simply have more commits 
> done by more people than most projects). I tend to do multiple merges a 
> day, so even though people linearize their history individually, you end 
> up seeing a fair amount of merges. But we'd have a lot _more_ of them if 
> people didn't try to keep history clean.

That's right the central semantics I have said, git tends to and recommends
a trunk mode development *on a high level*. It's not a bad thing.

> 
> Btw, in the absense of a merge, you can still tell who committed 
> something, exactly because git keeps track of "committer" information in 
> addition to "authorship" information. I don't understand why other 
> distributed environments don't seem to do this - because separating out 
> who committed something (and when) from who authored it (and when) is 
> actually really really important.

Yes, agree.

> 
> And that's not just because we use patches and other SCM's than just git 
> to track things (so authorship and committing really are totally separate 
> issues), but because even if the author and committer is the same person, 
> it's very instructive to realize that it might have been moved around in 
> history, so it might actually have been cherry-picked later, and the 
> committer date differs from the author date even if the actual author and 
> committer are the same person (but you might also have had somebody _else_ 
> re-linearize or otherwise cherry-pick the history: again, it's important 
> to show the committer _separately_ both as a person and as a date).
> 
> And because there is a committer field, if you actually want to linearize 
> or log things by who _committed_ stuff, you can. Just do
> 
> 	git log --committer=torvalds
> 
 > on the kernel, and you can see the log as it pertains for what _I_
 > committed, for example. You can even show it graphically, although it
 > won't be a connected graph any more, so it will tend to be very ugly
 > (but you'll see the "linear stretches" when somebody did some work). Just
 > do "gitk --committer=myname" to see in your own project.
 >
 > 		Linus

I want to separate a branch, not to separate commits by some author, for 
example, many authors can contribute to git's master branch, I want to
know what happened in the master branch like this:
      good work from A;
      good work from C;
      merge from next;   -----> I don't care how this feature is realized.
      good work from A;
      ....

As Junio points out, HEAD^1 is not always the tip of working branch,
so "git log" can't never satisfy me. There is reflog, but it's not public.

BTW: I have a great respect for any man who contributes to Linux and GIT,
especially you:-)