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: git commit/push and VC Date: Sat, 22 Nov 2014 10:35:26 +0200 Message-ID: <837fyntyy9.fsf@gnu.org> References: <871toysqyq.fsf@rosalinde.fritz.box> <838uj57u5b.fsf@gnu.org> <87ppchd9dk.fsf@Gertrud.fritz.box> <83fvdd612c.fsf@gnu.org> <87h9xttmwa.fsf@uwakimon.sk.tsukuba.ac.jp> <83oas13p1y.fsf@gnu.org> <87egsvu7iw.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416645350 31343 80.91.229.3 (22 Nov 2014 08:35:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 08:35:50 +0000 (UTC) Cc: Stromeko@nexgo.de, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 09:35:38 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 1Xs6AM-0001rd-4B for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 09:35:38 +0100 Original-Received: from localhost ([::1]:44381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs6AL-0003V0-MZ for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 03:35:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs6AD-0003Ut-Kh for emacs-devel@gnu.org; Sat, 22 Nov 2014 03:35:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xs6A8-0004RN-QZ for emacs-devel@gnu.org; Sat, 22 Nov 2014 03:35:29 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xs6A8-0004RG-JE for emacs-devel@gnu.org; Sat, 22 Nov 2014 03:35:24 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NFF00F00M37W300@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 22 Nov 2014 10:35:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFF00FKLMIYKC50@a-mtaout20.012.net.il>; Sat, 22 Nov 2014 10:35:22 +0200 (IST) In-reply-to: <87egsvu7iw.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:177974 Archived-At: > From: "Stephen J. Turnbull" > Cc: Stromeko@nexgo.de, > emacs-devel@gnu.org > Date: Sat, 22 Nov 2014 14:30:15 +0900 > > Eli Zaretskii writes: > > > From: "Stephen J. Turnbull" > > > > 3) multiple clones, build per clone (I don't think it much matters > > > whether it is in-tree or not, and people who use out-of-tree builds > > > probably have other reasons for doing that already, and they'll > > > know what they are doing). Disadvantages: one of the clones will > > > be used for "stable" -> trunk merges and reverse cherry-picking, > > > and you need to keep track of which one. You also need a lot more > > > VCS operations to keep them in synch. > > > I tend to recommend 3), but I don't understand the disadvantages; can > > you elaborate? I thought it was possible to merge between clones, are > > you saying that's not a good idea? > > The disadvantages are relatively minor. Technically speaking, it's > not possible in git to merge between clones, you have to fetch and > then merge (== pull). So to do that inter-clone merge, one would need git fetch ../my-other-clone git merge # fix conflicts, if any git commit -a # only if there were conflicts git push Is that right? Sounds a bot complicated and error-prone, I agree. How about the following alternative instead: we do NOT recommend merging from the other clone. The other clone is to be used only for committing to the release branch and, rarely (probably never) branching off that release branch for doing something that is not a trivial one-off fix. To merge to master, we recommend using the clone that is normally used for working on master and on feature branches (a.k.a. "master clone"). Specifically, when the time comes to merge the changes on the release branch to master, we recommend this sequence of commands in the "master clone": git pull git merge -m remotes/origin/emacs-24 # fix conflicts, if any # run tests, fix bugs if any git commit -a # only if there were conflicts git push Is this correct? Because if it is, it's just like the "normal" merge workflow, just with the name of the merge source branch slightly special. So it's easier to remember and less error-prone, I think. The main point is to avoid "git checkout emacs-24" in the "master clone" as much as possible, because once you switch back to master, the build will most probably be annoyingly long. > Another issue is that I find it easy to do fixes to the "wrong" branch > in the current repo, and that gets confusing. Does that happen with separate clones also? I thought separate clones make this less likely, since they allow you to seldom, if ever, switch between master and the release branch in the same repo. > Finally, I just find it more efficient to work in a single clone. I agree, but I think the Emacs use case is special in this respect, especially for people who are not proficient enough with Git.