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 19:39:09 +0300 Message-ID: <83oan3onki.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> <834mowp7cj.fsf@gnu.org> <55200A71.9040902@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428165579 26013 80.91.229.3 (4 Apr 2015 16:39:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 16:39:39 +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 18:39:33 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 1YeR6Z-0008IE-00 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 18:39:31 +0200 Original-Received: from localhost ([::1]:33726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeR6Y-00065N-C3 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2015 12:39:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeR6I-00061m-HM for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YeR6F-0003Tr-2L for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:39:14 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:33666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YeR6E-0003TZ-Kr for emacs-devel@gnu.org; Sat, 04 Apr 2015 12:39:11 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NMA00A00J68E300@mtaout27.012.net.il> for emacs-devel@gnu.org; Sat, 04 Apr 2015 19:34:00 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMA0033CJCOX860@mtaout27.012.net.il>; Sat, 04 Apr 2015 19:34:00 +0300 (IDT) In-reply-to: <55200A71.9040902@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.183 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:184878 Archived-At: > Date: Sat, 04 Apr 2015 17:59:45 +0200 > From: martin rudalics > CC: stephen@xemacs.org, sorganov@gmail.com, emacs-devel@gnu.org > > >> (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. I don't think such a discussion belongs to that page. Those are cookbook style instructions, so discussing things not directly referenced in the instructions should be avoided. > 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. Yes, and I already added that, please take another look. > > 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. I tried to explain that in the latest changes. > >> (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. Right, so they are both described now. > > 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 don't see this infinite loop (I tried with 2 local repositories instead). After the second commit, a pull says "already up-to-date". Not sure why the difference. > >> (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. I'd like to avoid additional commands, if possible. So I describe how to solve the conflicts by committing local changes in the files that prevented the merge. > > 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. I think we should remove rebasing from that page as well. It is there because we originally thought "pull --rebase" was a good idea. That was before we understood the damage it could cause in an otherwise merge-based workflow, including what gitmerge.el does when it merges from the release branch. > Thank you for working on this. I'm afraid it's no real fun. I don't play with Git for fun.