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

From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Date: Nov 20, 2006, 17:09 UTC
Message-ID: <200611201709.kAKH9or1012062@laptop13.inf.utfsm.cl>
In-Reply-To: <git2eran@tromer.org>

Eran Tromer <git2eran@tromer.org> wrote:

[...]

Show 20 quoted lines

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

I don't see the usefulness of this.

> Of course, you could just fast-forward instead:
> 
>   A--B--C--D--E master

Yep.

> but then you lose a meaningful and useful part of the historical record.

And if quux merges back, she gets the same plus a new merge node, and... Linus told everybody (quite forcefully, I might add) that this is not acceptable for distributed development.

> There are the obvious bad consequences if you make this the default,
> but how about adding a --force-commit option to merge and pull?

Fast forward is fast forward. Merge is when /independent/ changes are integrated into one.

> You'd need to educate users on how to use this responsibly

Looks like you've never met real users ;-)

>                                                            to avoid
> noise, but that's not any different from existing stuff like rebase and
> revert. Most users won't even know it exists.

Show 7 quoted lines

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

But the individual changes will presumably reflect said someone's authorship. If they are interleaved with stuff by others or not doesn't make much (development) sense. Yes, it might be interesting for a software historian, but that's not git's main audience in the first place.

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239