From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Messing with the VC history Date: Sun, 16 Nov 2014 17:05:28 +0100 Message-ID: <871tp3rv07.fsf@wanadoo.es> References: <87k32vsm8u.fsf@wanadoo.es> <83fvdjdv8t.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1416153972 29840 80.91.229.3 (16 Nov 2014 16:06:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 16:06:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 16 17:06:05 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xq2Kz-00062m-0d for ged-emacs-devel@m.gmane.org; Sun, 16 Nov 2014 17:06:05 +0100 Original-Received: from localhost ([::1]:44232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2Ky-0006Ii-JQ for ged-emacs-devel@m.gmane.org; Sun, 16 Nov 2014 11:06:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2Kh-0006IP-8a for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:05:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq2Kb-0007cO-NB for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:05:47 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:52477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2Kb-0007cD-Gf for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:05:41 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xq2Ka-0005tr-EQ for emacs-devel@gnu.org; Sun, 16 Nov 2014 17:05:40 +0100 Original-Received: from 132.red-79-158-48.staticip.rima-tde.net ([79.158.48.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 17:05:40 +0100 Original-Received: from ofv by 132.red-79-158-48.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Nov 2014 17:05:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 65 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 132.red-79-158-48.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:Qt7MwaYHo2lYHLOt1JRsjJhNMys= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177314 Archived-At: Eli Zaretskii writes: >> From: Óscar Fuentes >> 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.