From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Git transition workflow Date: Wed, 13 Aug 2014 12:59:42 +0900 Message-ID: <87iolxhwep.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2720487.3bKIskrhp0@descartes> <87sil214zs.fsf@drakenvlieg.flower> <87lhqtv7vf.fsf@Rainer.invalid> 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 1407902421 20217 80.91.229.3 (13 Aug 2014 04:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Aug 2014 04:00:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 13 06:00:13 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 1XHPjP-00035G-Hk for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2014 06:00:11 +0200 Original-Received: from localhost ([::1]:44895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHPjP-0000Yy-7b for ged-emacs-devel@m.gmane.org; Wed, 13 Aug 2014 00:00:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHPjC-0000Vj-Jt for emacs-devel@gnu.org; Wed, 13 Aug 2014 00:00:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHPj5-000359-45 for emacs-devel@gnu.org; Tue, 12 Aug 2014 23:59:58 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:48016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHPj4-00034q-KM for emacs-devel@gnu.org; Tue, 12 Aug 2014 23:59:51 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 448D1970B18; Wed, 13 Aug 2014 12:59:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 32E931A2834; Wed, 13 Aug 2014 12:59:42 +0900 (JST) In-Reply-To: <87lhqtv7vf.fsf@Rainer.invalid> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:173612 Archived-At: Achim Gratz writes: > Jan Nieuwenhuizen writes: > > Daily work > > If you=E2=80=99re using the command-line: > > > > git pull > > > > May I suggest to change this to > >=20=20 > > git pull --rebase / git pull -r > > > > or we're going to see a whole lot of merge commits. This requires people who don't already know how to "git rebase" to learn it (I mean the resolution workflow, not the command, of course). It will get a lot of pushback, and I expect that those users will revert to "git pull". On the other hand, merge conflicts are familiar from ancient times, and doesn't require learning a new workflow. You'll probably get used to it; I did when XEmacs moved to hg (and after several years of git use with rebasing before pushing, I was pretty disgusted by the XEmacs repo's DAG in the early days). It was not a big deal for most of our developers, so I accepted the inevitable. You probably should too. It should be "easy" to write a commit hook that just exchanges parents of a merge commit when the first parent's committer (author?) is the same as the merge commit's and the other parent is different. This (with high probability) preserves the mainline in a bzr-like fashion, and would be easy for CVS-like users to adopt (since only the merge commit object is manipulated, and that is automagic, no workflow change is involved). Then developers who really hate "redundant" merge commits can use "log --first-parent" to see pretty much what they want (the merge commit that integrates a trivial one-or-two-commit branch, and rebased commits that fast-forward when pushed). You'll miss important history from a few feature branches, but that's generally fixable with "log --committer" (plus --date or --skip to drill down). This is a workflow change for you, I grant, but you are more able to adopt it easily or do without, and your decision affects only you. Note that I generally agree with you about best practice (and disagree with the "even private history is sacred"/"rebased commits need testing" crowd). However, as I wrote before, Emacs doesn't *need* such best practice (let alone generally conform to it currently), and my experience with the Python, XEmacs, and Emacs CVCS-to-DVCS migrations is that trying to implement workflow changes at the same as changing VCSes doesn't work -- people too important to discipline balk and/or threaten to delay the move (cf. "vc-find-conflicting-files must work"), new committers don't know about the policies, etc. Take an improvement in=20