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 17:40:35 +0300 Message-ID: <838ueezgyk.fsf@gnu.org> References: <86egoeusg2.fsf@example.com> <87384qzxqy.fsf@igel.home> <83bnjen71r.fsf@gnu.org> <871tk6538w.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1427726479 23218 80.91.229.3 (30 Mar 2015 14:41:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Mar 2015 14:41:19 +0000 (UTC) Cc: sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca To: Mike Gerwitz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 30 16:41:11 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 1YcasH-0002Ba-T7 for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 16:41:10 +0200 Original-Received: from localhost ([::1]:34378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcasH-00078j-AC for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 10:41:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycas6-00071F-9R for emacs-devel@gnu.org; Mon, 30 Mar 2015 10:41:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ycarz-00030p-Tp for emacs-devel@gnu.org; Mon, 30 Mar 2015 10:40:57 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:41009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycarz-00030b-HJ; Mon, 30 Mar 2015 10:40:51 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NM100M0048Z9R00@mtaout29.012.net.il>; Mon, 30 Mar 2015 17:38:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM100N994NGKJ10@mtaout29.012.net.il>; Mon, 30 Mar 2015 17:38:05 +0300 (IDT) In-reply-to: <871tk6538w.fsf@gnu.org> 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:184547 Archived-At: > From: Mike Gerwitz > Cc: Stefan Monnier , sva-news@mygooglest.com, schwab@suse.de, eliz@gnu.org, emacs-devel@gnu.org > Date: Mon, 30 Mar 2015 03:54:55 -0400 > > > I have not yet seen a definitive answer about whether git reset is a > > reliable fix for that. > > 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, and ended with them committed locally, but not pushed upstream. IOW, the command did half the work, and now the user needs to use commands she might consider "advanced" to fix that. > 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. > In your case, since you just want to commit and push in one operation, > you likely want to run `git pull --rebase`, which would get those > changes and then automatically re-commit your work on top of them, as if > you had those changes all along. We decided some time ago that we don't want to rebase, but to pull instead. > But what if rebasing fails? Then you are left resolving a conflict > before you can attempt the push operation again. I do not know how you > would want to handle this. Ideally, "C-x v v" should DTRT in that case. But no one coded it to do that, yet. > This will be how the majority of Git users will resolve rejected pushes. Are you sure there's such a majority? I don't consider myself a Git expert, but even I can propose at least 3 different ways of dealing with the above situation. Ideally, someone who _is_ an expert will suggest the best way, and then "C-x v v" could be amended to support that. In any case, I think it is clear now that post-commit hooks cannot be the solution, because they are not versatile enough, and because user interaction will almost certainly be needed during resolution of such situations. > [Aside: `git pull` without `--rebase` performs a `git fetch && git > merge whatever-branch-you-are-tracking`, which has the unfortunate > side-effect of creating a merge commit if histories are different; > this muddies up history. We already decided not to worry about this, since we use a merge-based workflow with the release branch anyway (see admin/gitmerge.el). > For other users, it may represent a wholly different problem. For > example, if I were to push to GNU ease.js' repo and get that message, > that would be a problem, since that means that someone has committed to > my repository without my permission. An automatic pull and re-push > would be bad in this case, since that makes it look like I'm okay with > that. First, no one suggested any automation here. "C-x v v" is a command that is invoked by the user, it doesn't invoke itself. It could also show a warning and ask for confirmation in dubious situations. And second, with VCSes as versatile as Git (and assuming that people who use Git in such workflows will at all want to use VC, an assumption that proved questionable in this discussion), VC should offer to customize its "next action" decisions so as to adapt them to a particular workflow. > A failed push could also mean that you are tracking the wrong > branch, or pushing to the wrong repository. Git allows you to set a > "tracking branch", which can be anything---a local branch, a remote > branch, or a branch in an entirely different repository, local or > remote. Further, you can override the tracking branch by specifying > which remote to push to as part of the `push` command. "C-x v v" is not supposed to be able to cover every contingency and every workflow out there. It should support the widely used ones, and left the rest to manual invocation of commands at user discretion. > A failed push could also mean that someone rudely rewrote history on the > remote branch (using `git push --force`) and someone needs a talkin' to. When a push fails, the user should read the error message, and try to understand what it means. There's no way around that; no one is suggesting that only the exit status of the push command is enough to decide what to do next.