On 2006-11-20 05:21, Junio C Hamano wrote:
> linux@xxxxxxxxxxx writes:
>> (Indeed, it might be nice to come up with a way of including a piece of
>> the "please pull" e-mail, similar to the way that git-applypatch works.)
>
> That is a lot more relevant example. For example, I could
> imagine that Linus coming up with a wrapper that is fed a series
> of e-mails and:
>
[snip]
> - otherwise annotate the commit message with the explanation
> of the series taken from the pull request message.
[snip]
> - People can say "git pull -m 'I am doing this merge for such
> and such reason' $URL $branch" to _include_ that message in
> the resulting merge commit;
>
> - The same can be said about "git merge -m 'comment' $branch".
What about fast forwards? Do you get to record the explanation for the
series only if the guy you pulled from didn't bother to do a rebase?
That's broken.
Let's face it, the merge commits generated when pulling have two
completely independent uses:
1. They're technically necessary for joining DAG nodes that don't all
lie on one path.
2. They're useful as a record of workflow and a place to put comments.
The two uses are nearly independent.
Consider the following silly DAG.
A------------F master
\ /
B--C--D--E
Yes, E and F have identical trees. But it's actually *very useful*, if
the commit message at F says "merged branch foo containing experimental
bar from quux". And it shows up nicely when looking at gitk.
Of course, you could just fast-forward instead:
A--B--C--D--E master
but then you lose a meaningful and useful part of the historical record.
There are the obvious bad consequences if you make this the default,
but how about adding a --force-commit option to merge and pull?
You'd need to educate users on how to use this responsibly to avoid
noise, but that's not any different from existing stuff like rebase and
revert. Most users won't even know it exists.
And to answer Linus: yes, it's expected that only non-leaf developers
will use --force-commit on regular basis, but that's not because
maintainers are technically special in any way. It's just because
maintainers have something useful to say ("someone's private topic
branch, starting at A and ending at E, has just been accepted into my
all-important public repo and here's why"). Anyone else can do the same
if he feels likewise.
Eran
-
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