From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: Messing with the VC history
Date: Sun, 16 Nov 2014 17:05:28 +0100 [thread overview]
Message-ID: <871tp3rv07.fsf@wanadoo.es> (raw)
In-Reply-To: 83fvdjdv8t.fsf@gnu.org
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.
next prev parent reply other threads:[~2014-11-16 16:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 6:17 Messing with the VC history Óscar Fuentes
2014-11-16 8:19 ` Achim Gratz
2014-11-16 15:25 ` Eli Zaretskii
2014-11-16 16:00 ` David Engster
2014-11-17 16:48 ` Eli Zaretskii
2014-11-16 16:33 ` Achim Gratz
2014-11-16 18:13 ` Eli Zaretskii
2014-11-22 10:04 ` Steinar Bang
2014-11-16 15:24 ` Eli Zaretskii
2014-11-16 16:05 ` Óscar Fuentes [this message]
2014-11-16 16:21 ` Eli Zaretskii
2014-11-16 23:33 ` Stephen J. Turnbull
2014-11-17 1:31 ` John Yates
2014-11-17 3:23 ` Stephen J. Turnbull
2014-11-18 7:18 ` Lars Brinkhoff
2014-11-18 7:42 ` David Kastrup
2014-11-18 7:53 ` Stephen J. Turnbull
2014-11-18 8:41 ` David Kastrup
2014-11-18 16:47 ` Barry Warsaw
2014-11-18 17:06 ` Andreas Schwab
2014-11-18 22:30 ` Stephen J. Turnbull
2014-11-19 2:34 ` Stefan Monnier
2014-11-17 16:42 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871tp3rv07.fsf@wanadoo.es \
--to=ofv@wanadoo.es \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.