From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Mon, 06 Apr 2015 03:45:32 +0900 Message-ID: <87fv8efm7n.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <83oan3onki.fsf@gnu.org> <87sicffqma.fsf@uwakimon.sk.tsukuba.ac.jp> <834movnjm0.fsf@gnu.org> <87lhi7ezge.fsf@uwakimon.sk.tsukuba.ac.jp> <83y4m6n4j0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1428259560 19275 80.91.229.3 (5 Apr 2015 18:46:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 18:46:00 +0000 (UTC) Cc: rudalics@gmx.at, sorganov@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 05 20:45:48 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 1YepYK-0003Pz-4i for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 20:45:48 +0200 Original-Received: from localhost ([::1]:37322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YepYJ-0001m6-Jb for ged-emacs-devel@m.gmane.org; Sun, 05 Apr 2015 14:45:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YepYF-0001lq-7p for emacs-devel@gnu.org; Sun, 05 Apr 2015 14:45:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YepYD-0004JL-Mn for emacs-devel@gnu.org; Sun, 05 Apr 2015 14:45:43 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:32837) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YepY7-0004I3-Rd; Sun, 05 Apr 2015 14:45:36 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 3EC191C387E; Mon, 6 Apr 2015 03:45:33 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 19E57120EC9; Mon, 6 Apr 2015 03:45:33 +0900 (JST) In-Reply-To: <83y4m6n4j0.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:184962 Archived-At: Eli Zaretskii writes: > > Richard will speak for himself about the size of the price, but I > > suspect he doesn't need to pay it at all in the current case (see my > > other post, specifically about "git commit --include" > > Maybe I'm missing something, but I don't understand how --include > could have helped in this case. Well, as you wrote elsewhere, if he's using VC there's a save-hook (in smerge-mode?) that automatically adds the file whose conflicts are fixed, and --include is a no-op. > So AFAIU "git commit --include FILE" is equivalent to these two > commands: > > git add FILE > git commit Yes. That's how I understand the man page, too, and it corresponds to the experiments I did. > If this is true, then this will commit both the file with conflicting > uncommitted changes and the rest of the stuff fetched from > upstream. True. > So how is it different from what I described on the Wiki? The result > is the same: the changes that were left uncommitted because they are > "not ready" will end up committed. My procedure is IMO better in that > it doesn't require any non-default switches to commands. Probably it isn't any different. It's just that I was unclear on what was going to be committed. In fact, as long as the developer restricts himself to committing merged files (including but not limited to those with resolved conflicts) it's possible it's exacty what Richard wants: leave the files containing changes needing further testing uncommitted. But: > > He will need to do something else in the case that he runs into the > > "will overwrite your changes" message. > > But that's exactly the situation I thought we were discussing: > uncommitted changes that conflict with changes upstream. So now I'm > confused about the use case you referred to above. But I'm trying to look at this from Richard's point of view int he current situation. As far as I can tell that's not the case in Richard's current workspace, except for lisp/ChangeLog, and that's already a special case in his workflow since he didn't write it up until after he did the pull (but did do the code changes before the pull). It's also a special case in Emacs, since the ChangeLog update actually belongs to the merge in some sense. > > However, since he seems comfortable with the "don't touch > > ChangeLogs until after you pull" workflow, I'm guessing the > > probability that he'll run into something really ugly is > > unlikely. > > Agreed, and that's why I think stash could be avoided. Unfortunately, there's the case that hasn't been mentioned explicitly, which is where he has a code change that touches multiple files, some of which are conflicted and some of which are not. The conflicted files have to be committed to keep git happy unless you do some "advanced" stuff, such as stash. I don't think you really want Richard's changes mixed with merge changes.