Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> From: Mike Gerwitz <mikegerwitz@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  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.