From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Sat, 04 Apr 2015 17:59:45 +0200 Message-ID: <55200A71.9040902@gmx.at> 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> <834mowp7cj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1428163263 21667 80.91.229.3 (4 Apr 2015 16:01:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 16:01:03 +0000 (UTC) Cc: stephen@xemacs.org, sorganov@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 04 18:00:55 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 1YeQV8-00072F-D1 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 18:00:50 +0200 Original-Received: from localhost ([::1]:33518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeQV7-0004RP-Bq for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 12:00:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeQUQ-0004LJ-Gw for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:00:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YeQUP-0000m7-47 for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:00:06 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:54501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeQUI-0000ZE-Mr; Sat, 04 Apr 2015 11:59:58 -0400 Original-Received: from [178.189.205.199] ([178.189.205.199]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVayZ-1YvrfA1wJ5-00YzKK; Sat, 04 Apr 2015 17:59:55 +0200 In-Reply-To: <834mowp7cj.fsf@gnu.org> X-Provags-ID: V03:K0:Z/QTy38xmRw6oTqddCo8shf82+UkC9SL536Je9N6mgR+oYMyi4M vJWBkJbdL3vh9TNyKq8+HKOcTPMFMu7d6y+LPROCBYarv8w9QazWmitNh6f17HFP7Pf18UY prk64NkJwZMOnJz3J4gL8lKfgd4O8Ko+kAIrVJO8xsKI9rof4yHzWY/rR3SuJW71N0yHkpc Cqkc2KAUh9PIq26D5jSjQ== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.22 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:184875 Archived-At: >> (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? According to this thread there are people who recommend to never pull but always do fetch and merge instead. We should say whether they are right. And we probably should tell what happened after git pull with the following error: Your local changes to the following files would be overwritten by merge: ... Please, commit your changes or stash them before you can merge. Aborting AFAICT this signlas a succeeding fetch and a failing merge. > 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. IIUC git's pull is not atomic. When the merge fails with a message like the above I have no idea in what state my copy of a repository is in. Well, I wouldn't know even without that message ... > 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, In the one case I get the message cited above. In the other case I get conflicts and git asks me to resolve them. > 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. Now suppose that, in reaction to the message above I do git commit -a git pull and now am told to resolve my conflicts. I do that via smerge-mode, save the file(s) which had the conflict(s) and do git commit as recommended. I tried that just now with a conflict in Changelog. After this git told me that On branch master Your branch and 'origin/master' have diverged, and have 2 and 74 different commits each, respectively. (use "git pull" to merge the remote branch into yours) All conflicts fixed but you are still merging. (use "git commit" to conclude merge) and, after the recommended git pull CONFLICT (content): Merge conflict in lisp/ChangeLog Automatic merge failed; fix conflicts and then commit the result. just that I did not find any conflicts at this stage. So I practically ended up in an infinite loop which I was able to break only via a hard reset. I suppose this is similar if not identic to Richard's original problem which is apparently very easily reproducible here. >> (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. Stashing is offered in the first git message cited above. If it's bad we should tell people why. OTOH I never had a problem with stashing and in particular it never got me into the loop I mentioned later. > 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? I never used rebasing and can't tell whether it's of any use. But it is propsed in GitForEmacsDevs and it's very confusing if we have two texts with a similar purpose proposing different things. > 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. If the cookbook instructions are fail-safe there's no problem. I'm afraid they aren't. > Those are my thoughts, feel free to point out where I'm wrong. > > Thanks. Thank you for working on this. I'm afraid it's no real fun. martin