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:-)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html