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: VC mode and git Date: Sat, 04 Apr 2015 12:31:56 +0300 Message-ID: <834mowp7cj.fsf@gnu.org> References: <83twx2xoc8.fsf@gnu.org> <87619hke3u.fsf@uwakimon.sk.tsukuba.ac.jp> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331214347.GH2871@acm.fritz.box> <20150401103225.GA2633@acm.fritz.box> <87h9t080gx.fsf@javad.com> <83384jsx3o.fsf@gnu.org> <83pp7nrfdn.fsf@gnu.org> <83a8yqr226.fsf@gnu.org> <831tk2qvz5.fsf@gnu.org> <87384ii26v.fsf@uwakimon.sk.tsukuba.ac.jp> <83wq1tptvp.fsf@gnu.org> <87pp7lhc9h.fsf@uwakimon.sk.tsukuba.ac.jp> <83sichpqe9.fsf@gnu.org> <87ioddglu6.fsf@uwakimon.sk.tsukuba.ac.jp> <83a8yoq56m.fsf@gnu.org> <87384ghm1a.fsf@uwakimon.sk.tsukuba.ac.jp> <837ftspcis.fsf@gnu.org> <551FA115.5090400@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428139939 20044 80.91.229.3 (4 Apr 2015 09:32:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 09:32:19 +0000 (UTC) Cc: stephen@xemacs.org, sorganov@gmail.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 04 11:32:09 2015 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 1YeKQz-0004kt-Ip for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 11:32:09 +0200 Original-Received: from localhost ([::1]:36721 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeKQy-0008C9-V0 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 05:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeKQv-0008Bq-7Y for emacs-devel@gnu.org; Sat, 04 Apr 2015 05:32:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YeKQq-0002GQ-6O for emacs-devel@gnu.org; Sat, 04 Apr 2015 05:32:05 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:54323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeKQp-0002G4-QH for emacs-devel@gnu.org; Sat, 04 Apr 2015 05:32:00 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NM900800ZELUO00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:29:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM90060EZP4NM30@mtaout29.012.net.il>; Sat, 04 Apr 2015 12:29:28 +0300 (IDT) In-reply-to: <551FA115.5090400@gmx.at> 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.185 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:184857 Archived-At: > Date: Sat, 04 Apr 2015 10:30:13 +0200 > From: martin rudalics > CC: sorganov@gmail.com, emacs-devel@gnu.org > > > I gathered enough stuff in this thread to fix GitQuickStartForEmacsDevs, > > to which I'd appreciate comments from everyone who has a moment to > > spare. > > Thanks. Please consider the following: Thank you for your comments. > (1) Say that a pull is a fetch plus a merge and what these do. Why would that matter for people who just want to copy their mental models from CVS to Git with minimal changes? Every VCS does some kind of a fetch and a merge when it pulls. Git and AFAIK also Mercurial are unique in that they let the user invoke each of these separately. But IMO that only matters if we then explain how to use these separate steps to the user's benefit, and I don't see how doing so is possible, let alone necessary, within a CVS-like workflow. Maybe I'm missing something, so please elaborate why you thought this to be beneficial. > (2) Distinguish the two ways a merge can fail: The one where git refuses > to merge because it would overwrite changes and the second one where > it detects conflicts. And how to deal with them. I think the way to deal with both is the same, and that's what the instructions describe. Again, maybe I'm mistaken, but then please show an example where the instructions would fail in one of those cases. The intent is to try to preserve the CVS mental models, so the description generally follows what one would do with conflicts created by "cvs update", the only changes being those that are strictly necessary with Git. > (3) Mention both stashing and rebasing. IMO it's no use ignoring them. > People will find them in the manuals and tutorials and we should at > least tell them why the method we propose here is sufficient or > better. The fact that these are mentioned in the manuals is not a good guidance for mentioning them, since the manuals mention a lot more than just these two. Stashing was not mentioned there to begin with; it isn't even mentioned in the more advanced GitForEmacsDevs page, nor was its bzr equivalent ever mentioned in the instructions we wrote for Bazaar. CVS has no equivalent for stashing. So I'm not sure why you think it should be mentioned. Perhaps the reason is that you yourself use it a lot. Once again, please elaborate. Rebasing is a tricky issue. Richard asked (off-line) for an explanation of what it is, so the notion itself is not immediately clear to everyone, and would need to be explained. Next, we decided not to recommend rebasing (because we merge from the release branch, and generally prefer merge-based workflows), so if we want the readers of those instructions to use rebase, we must describe it as a marginal feature for rare situations. Is it worth that, and if so, why? It is possible that both of these issues could be explained in a separate section near the end of the page, as some additional stuff worth learning. But then (a) we should think carefully how we would like to categorize them, and (b) there's a real danger people won't read something that has no direct bearing on the otherwise cookbook-like approach of the instructions. Those are my thoughts, feel free to point out where I'm wrong. Thanks.