Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Mike Gerwitz <address@hidden>

 > > 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.