Re: VC mode and git

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > It did?  It's not clear to me.  I still haven't seen an explanation of
 > > how he ended up with a ton of modified files that he didn't touch, or
 > > how he's going to get past that safely.
 > 
 > We've been through that: those are files from the merge already in the
 > index, ready to be committed when the conflicts are resolved.

I've been through that too, I tried to reproduce and failed.  My
understanding was that Richard had edited and had uncommitted changes
*before* "the" pull.  Both in theory and by experiment, there should
be no merge in the index.  The merge doesn't even get started if
conflicts are expected and there are uncommitted changes.  The reflog
also didn't show any pull since the commits Richard did make.

So your hypothesis is something like

1. Richard cloned the repo.
2. He did the edit-commit cycle three times (according to reflog).
3. At some point, he did a couple of branch switches (according to
   reflog; result was a no-op).
3. He pulled (when fully committed), and got a conflict in
   lisp/Changelog during the merge phase (so no reflog entry).
4. He hasn't edited since (except maybe the ChangeLog)
5. Maybe he has pulled since, but that would have no visible changes
   (there would be a fetch to origin/master, but no merge at all).

?

In that case, yes, commit-pull[-fix-commit]?-push should do the
trick.  I would recommend a diff (or diffstat) against origin/master
to make sure he recognizes all the changes as his own before pushing.