[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Messing with the VC history
From: |
Óscar Fuentes |
Subject: |
Re: Messing with the VC history |
Date: |
Sun, 16 Nov 2014 17:05:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: Óscar Fuentes <address@hidden>
>> 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.
Re: Messing with the VC history, Eli Zaretskii, 2014/11/16
- Re: Messing with the VC history,
Óscar Fuentes <=
- Re: Messing with the VC history, Eli Zaretskii, 2014/11/16
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/16
- Re: Messing with the VC history, John Yates, 2014/11/16
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/16
- Re: Messing with the VC history, Lars Brinkhoff, 2014/11/18
- Re: Messing with the VC history, David Kastrup, 2014/11/18
- Re: Messing with the VC history, Stephen J. Turnbull, 2014/11/18
- Re: Messing with the VC history, David Kastrup, 2014/11/18
- Re: Messing with the VC history, Barry Warsaw, 2014/11/18
- Re: Messing with the VC history, Andreas Schwab, 2014/11/18