Re: Messing with the VC history

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Sun, 16 Nov 2014 07:17:05 +0100
>> 
>> To welcome my first commit to Emacs, some people complicated the VC
>> history with unnecessary noise burying the happy event into a
>> merge-fest.
>
> I see nothing terribly messy there.  You will see very similar picture
> when someone merges their local feature branch, and then pushes
> upstream.

That's not the same at all. Feature branches and incorporating changes
from other public development branches *shall* be merged. What I'm
describing is an scenario where merges are created just because someone
pushed changes since your last `pull'. Apart from the noise on the VC
history, this procedure has a recursive nature: A tries to push but he
can't because there are new commits on the remote branch; then he pulls
(+merges) and pushes. Meanwhile, B was hacking and now tries to push,
but he can't because the changes pushed by A, so he pulls (+merges).
Then C (or A again) tries to push...

A single hacker can create multiple merges just to commit one change: it
pulls and finds conflicts; he resolves them (a merge is created) and
tries to push, but meanwhile others pushed their changes, so he pulls
again. He now has a merge within a merge just to push one patch.

The result is an entangled DAG that makes very difficult and unpleasant
to read the VC history.

> Maybe you don't like merge-commits in general, but then it's a
> different discussion altogether.

I don't like merge commits that add nothing but noise and confussion to
the VC history.

>> IMO we should encourage people to use fetch+rebase instead of `pull',
>
> Why not "pull --rebase" instead?

Because people here work with at least two branches. "pull --rebase"
pulls from all remote branches, but only rebases the branch you are
working on (let's say `master'). So, when you switch to other branch
(`emacs-24') you must remember that there are changes not yet
incorporated into your emacs-24 checkout. Not a big deal, but IMO it is
a good thing to have an idea of what you are going to incorporate into
your local branch.

With the right tool (Magit, for instance) fetch+rebase is faster than
the command line (just type ffR) and you see at all times your changes,
the fetched commits, the rebase status, etc.

> Or even tell them how to configure
> Git to do the "--rebase" part automatically?  People shouldn't need to
> learn yet another command, just for that.
>
>> (I'll not dare to ask why, mysteriously, the emacs-diffs mailing list
>> abstained from mentioning my commit.)
>
> It didn't.  It's just that this is your first time, and emacs-diffs is
> a moderated list, so I needed to approve your messages, just this
> once.  Part of your welcome party, I guess.

I feel so especial today.