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 transition checklist Date: Wed, 08 Jan 2014 22:52:21 +0200 Message-ID: <83sisydwmy.fsf@gnu.org> References: <20140108135200.8ECF9380834@snark.thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389214359 31680 80.91.229.3 (8 Jan 2014 20:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 20:52:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: esr@thyrsus.com (Eric S. Raymond) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 21:52:45 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 1W107I-00032U-Io for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 21:52:44 +0100 Original-Received: from localhost ([::1]:48902 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W107I-0001ji-8l for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 15:52:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1079-0001hF-0I for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:52:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1072-0002d1-JF for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:52:34 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1072-0002cp-Ad for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:52:28 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZ300M00OJ4DE00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 08 Jan 2014 22:52:26 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ300MCKONE4P70@a-mtaout20.012.net.il>; Wed, 08 Jan 2014 22:52:26 +0200 (IST) In-reply-to: <20140108135200.8ECF9380834@snark.thyrsus.com> 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:167808 Archived-At: > From: esr@thyrsus.com (Eric S. Raymond) > Date: Wed, 8 Jan 2014 08:52:00 -0500 (EST) > > > 5. Have the procedures and the recommended workflows described on the > > wiki, similar to what was done with bzr migration. > > That is now done. I have created two new pages on EmacsWiki, > GitForEmacsDevs and GitQuickStartForEmacsDevs. These are adapted from > the corresponding *Bzr* pages but describe git commands to perform > equivalent operations. Thanks. I have some comments/questions on that: . The section about merging to the upstream master seems to omit "git push" after merging the task onto the master branch. It ends with the "git commit" command, which AFAIK is not the end of the story. . The few places that describe a merge from another branch seem to say that one needs to issue 2 commands: "git merge" and "git commit". Perhaps I'm confused, but isn't it true that "git merge" automatically commits if there are no conflicts? If I'm right, an explicit commit is needed after merge only when there are conflicts to be resolved. For the same reason, is "git revert" TRT when a push upstream fails after a merge from the local task branch, because someone else pushed meanwhile? The merge is already committed locally, so what will revert do? I think one will need "git reset" in this case. . I would suggest describing the setup of git-merge-changelog, because as long as we keep ChangeLog files in the repository, people might bump into conflicts in the logs, and it would be nice to avoid that. . I think we should discuss some more how to work with the development trunk and the release branch in parallel, and reflect the results of the discussion in the Wiki. The issue here is that the release branch and the trunk diverge very quickly after the branch point, and the result is that after you checkout the other branch, you generally need a very long build, many times a full bootstrap. While on a modern system, a full bootstrap should take a few minutes, it is still annoyingly long, and makes higher the risk of losing the race against other committers. In addition, you only have a single executable at any given time, so comparison of behavior between the two branches is difficult. So perhaps we should find a way of having two separate branches, such that switching between them does not require a build if nothing changed. > The only omission is that I left out the git equivalent of bzr bundle. I think the section about publishing a task was also omitted. Was that on purpose? > An interesting side effect of doing this translation, by the way, is > that I now know the exact git-command equivalents for the recommended > workflow in Bazaar. Rather to my surprise, the git procedures are > simpler! > > I'm surprised at this because Bazaar, whatever its other failings, had > a reputation as being simpler to use than git which I believed was > deserved. But, at least for the workflows described, git avoids so > much complexity and ceremony by not having the branch-vs.-repo > distinction that the gain from this swamps git's other UI > shortcomings. Can we please stop the apology and concentrate on the task at hand? This kind of comments can only annoy those who are still in mourning of the need to switch. (And no, I don't see how the git procedures are simpler, except due to some omissions and non-existent features, they are roughly the same.)