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: Mon, 30 Mar 2015 22:44:07 +0300 Message-ID: <83twx2xoc8.fsf@gnu.org> References: <86egoeusg2.fsf@example.com> <87384qzxqy.fsf@igel.home> <83bnjen71r.fsf@gnu.org> <871tk6538w.fsf@gnu.org> <838ueezgyk.fsf@gnu.org> <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427744691 560 80.91.229.3 (30 Mar 2015 19:44:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Mar 2015 19:44:51 +0000 (UTC) Cc: rms@gnu.org, sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org, mikegerwitz@gnu.org, monnier@iro.umontreal.ca To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 30 21:44:40 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 1Ycfby-0004bq-Ut for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 21:44:39 +0200 Original-Received: from localhost ([::1]:35756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycfby-0005rG-B9 for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 15:44:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycfbq-0005rA-Jx for emacs-devel@gnu.org; Mon, 30 Mar 2015 15:44:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ycfbj-0007lh-OC for emacs-devel@gnu.org; Mon, 30 Mar 2015 15:44:30 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:49082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycfbj-0007lF-B1; Mon, 30 Mar 2015 15:44:23 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NM100000IGKRC00@mtaout29.012.net.il>; Mon, 30 Mar 2015 22:41:36 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM100NTVIPCED20@mtaout29.012.net.il>; Mon, 30 Mar 2015 22:41:36 +0300 (IDT) In-reply-to: <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> 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:184565 Archived-At: > From: "Stephen J. Turnbull" > Date: Tue, 31 Mar 2015 04:24:48 +0900 > Cc: rms@gnu.org, sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org, > Mike Gerwitz , monnier@iro.umontreal.ca > > > 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. If it needs to cater to non-experts, let alone people who cannot afford or be bothered to learn enough of Git, it should also make sure the repository is left in a state from which it is easy to proceed with fixing whatever problems are left after backing out the commit. I'm not sure this is easy. But if someone who knows their ways around Git comes up with such a script, I'll be the first to applaud.