Re: Feature request: git-pull -e/--edit

From: Eran Tromer <git2eran@tromer.org>
Date: Nov 20, 2006, 13:42 UTC
Message-ID: <4561B0B5.1020305@tromer.org>
In-Reply-To: <7v8xi67qhq.fsf@assigned-by-dhcp.cox.net>

On 2006-11-20 05:21, Junio C Hamano wrote:

> linux@horizon.com writes:

Show 7 quoted lines

>> (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]

Show 5 quoted lines

>  - 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.