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: Tue, 31 Mar 2015 04:24:48 +0900 Message-ID: <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86egoeusg2.fsf@example.com> <87384qzxqy.fsf@igel.home> <83bnjen71r.fsf@gnu.org> <871tk6538w.fsf@gnu.org> <838ueezgyk.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 1427743538 12839 80.91.229.3 (30 Mar 2015 19:25:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Mar 2015 19:25:38 +0000 (UTC) Cc: rms@gnu.org, sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org, Mike Gerwitz , monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 30 21:25:22 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 1YcfJJ-00068D-Hx for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 21:25:21 +0200 Original-Received: from localhost ([::1]:35714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcfJI-0008NO-TP for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 15:25:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcfJE-0008N7-Re for emacs-devel@gnu.org; Mon, 30 Mar 2015 15:25:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcfJD-0002Gb-Ik for emacs-devel@gnu.org; Mon, 30 Mar 2015 15:25:16 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcfJ9-0001qC-Kp; Mon, 30 Mar 2015 15:25:12 -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 7E1C01C3851; Tue, 31 Mar 2015 04:24:48 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 53B5A120EC9; Tue, 31 Mar 2015 04:24:48 +0900 (JST) In-Reply-To: <838ueezgyk.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:184564 Archived-At: Eli Zaretskii writes: > > From: Mike Gerwitz > > If a push fails, that does not necessarily indicate a "bad > > state"---it simply represents that your history is different than > > what the remote server has, and that the tip of the branch you > > are pushing to cannot simply be "fast-forwarded" to your commit. > > It is "bad" from the POV of someone who started with uncommitted > changes, I don't think it's useful to call this "bad" or "a screw" (speaking of name-calling). However, Mike's answer clearly doesn't account for Richard's point of view. > > After a failed push, you are in no different state than you were > > before the push (aside from a possibly puzzled mental state). > > Yes, he is in a different state: before that, the changes were > uncommitted. Technically, Mike is right (he writes of before/after push, which is unambiguous). What he's missing is that the requirement is an atomic commit-and-push. > In any case, I think it is clear now that post-commit hooks cannot > be the solution, because they are not versatile enough, Eli, that's ridiculous. While I don't think it's obvious that a post-commit hook can meet all requirements (specifically, when I explained to Richard that files add'ed, rm'ed, or mv'ed since HEAD^ and committed in HEAD will be not be in the same state after "git reset --soft HEAD^", he characterized that as a defect in git), they come pretty close already (in Emacs practice, manipulations of directories are relatively rare, so this is going to bite only in very rare circumstances). I believe those are the only state changes that get reverted by reset --soft. File modifications are preserved, and I'm pretty sure that chmod is as well. Furthermore, a complex pre-commit hook probably can parse the output of git status and preserve the add/rm/mv state. Or maybe the thing to do is save the index (it may be possible to just stash that state, and I'm pretty sure it can be committed to a temporary branch, and restored from that if the push fails) -- that would preserve everything that's observable by git. > and because user interaction will almost certainly be needed during > resolution of such situations. That's not part of the requirement. Of course user interaction will be needed to deal with modification conflicts, and it's not obvious what the right thing to do in case of losing the push race. (Note: what's "right" *not* a question of "git expertise". That's purely a question of workflow, which is partly a project decision and partly a personal decision.) However, the requirement for the hook functions is to make it possible to commit and push as a single atomic operation.