Eran Tromer <git2eran@xxxxxxxxxx> wrote:
[...]
> 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.
> 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
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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