From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Messing with the VC history Date: Sun, 16 Nov 2014 18:21:26 +0200 Message-ID: <831tp3dsl5.fsf@gnu.org> References: <87k32vsm8u.fsf@wanadoo.es> <83fvdjdv8t.fsf@gnu.org> <871tp3rv07.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1416154934 12609 80.91.229.3 (16 Nov 2014 16:22:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 16:22:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 16 17:22:07 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 1Xq2aT-0003pC-S1 for ged-emacs-devel@m.gmane.org; Sun, 16 Nov 2014 17:22:06 +0100 Original-Received: from localhost ([::1]:44290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2aT-0003F6-EX for ged-emacs-devel@m.gmane.org; Sun, 16 Nov 2014 11:22:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2aA-0003Ew-AX for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:21:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq2a4-0003ZE-2f for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:21:46 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:42377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq2a3-0003Yy-MI for emacs-devel@gnu.org; Sun, 16 Nov 2014 11:21:40 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NF500N003EXLS00@mtaout24.012.net.il> for emacs-devel@gnu.org; Sun, 16 Nov 2014 18:14:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NF500F8A3REAE90@mtaout24.012.net.il>; Sun, 16 Nov 2014 18:14:02 +0200 (IST) In-reply-to: <871tp3rv07.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:177317 Archived-At: > From: =C3=93scar Fuentes > Date: Sun, 16 Nov 2014 17:05:28 +0100 >=20 > >> 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 pi= cture > > when someone merges their local feature branch, and then pushes > > upstream. >=20 > That's not the same at all. Feature branches and incorporating chan= ges > from other public development branches *shall* be merged. What I'm > describing is an scenario where merges are created just because som= eone > pushed changes since your last `pull'. But that's Git's default behavior: "merge" commits. So when Stefan merged from the branch, Git made a merge-commit, producing the same effect as if Stefan were to merge his local feature branch. What can we do if the tool behaves like that? > 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 ne= w > 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... Yes, but (a) this danger existed with bzr as well, and (b) the race you describe is in practice very rare, so the problem normally doesn'= t happen, and having it here and there is not different from local merges. > > Maybe you don't like merge-commits in general, but then it's a > > different discussion altogether. >=20 > I don't like merge commits that add nothing but noise and confussio= n to > the VC history. I didn't become confused when I looked at that part of the graph. > >> IMO we should encourage people to use fetch+rebase instead of `p= ull', > > > > Why not "pull --rebase" instead? >=20 > Because people here work with at least two branches. Who does? The recommendation is not to do that, because master and the release branch diverge very quickly, so switching branches will almost always require a full bootstrap. You are, of course, free to do that if you like, but then you probabl= y know what you are doing anyway. In contrast, forcing the (at least somewhat) confused majority to have yet another command in their everyday workflow means more pain for them. > With the right tool (Magit, for instance) fetch+rebase is faster th= an > the command line (just type ffR) and you see at all times your chan= ges, > the fetched commits, the rebase status, etc. We are talking about CLI commands here. Emacs front ends are a separate matter, they can simply automate everything, so people will not have to remember the Git commands that run under the hood. That'= s not the issue at hand. > >> (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-dif= fs is > > a moderated list, so I needed to approve your messages, just this > > once. Part of your welcome party, I guess. >=20 > I feel so especial today. You are. Welcome on board.