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

[Linus Torvalds <torvalds@osdl.org>]

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.

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.

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.

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.