Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sun, 05 Apr 2015 07:01:05 +0900
> 
> 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.

I'm not sure this is what happened; I think he had _committed_ changes
that conflicted.

Let's reiterate what Richard described in his original message:

    I committed some changes using C-x v v in vc-dir.
    Something went wrong with lisp/ChangeLog.

    It appears that my change log entries went into an old version of that
    file; I don't know why this happened, since I wrote them today after
    doing 'git pull'.

    After this, I did 'git pull' again, and it said there was a merge
    conflict in lisp/ChangeLpg.  A lot of text appears to be missing from
    the file.  It said, "fix conflicts and then commit the result."

    I edited lisp/ChangeLog and tried to commit it with C-x v v.
    That gave me the error message

      fatal: cannot do a partial commit during a merge.

    I am now stuck.  I don't know what a "merge" is; it is certainly
    nothing I asked to do.

Note the "merge conflict" part and the error message Richard cites:
"fix conflicts and then commit the result."  This is a message
displayed by Git when you have a conflict in _committed_ changes, and
the merge fails half-way through.  Error messages about conflicts in
uncommitted changes are different

The second error message, viz.:

  fatal: cannot do a partial commit during a merge.

is because "C-x v v" invokes "git commit --only lisp/ChangeLog", which
AFAIR always fails in this situation, for the reason hinted by the
error message.

The result of "git status -s" is consistent with the hypothesis that
the only problem during pull was conflicting changes in
lisp/ChangeLog.  The uncommitted changes, if there were present,
didn't generate conflicts, and so were silently kept by the merge.

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

Yes, something like that.  In fact, I think the root cause of the
original problem was that "C-x v v", which tried to commit a single
file in the middle of a merge.  Instead, the correct action is either
'v' from vc-dir or "git commit" from the shell prompt.

It would be good if "C-x v v" tried to support this situation better.
I hope Eric Raymond is reading this.

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

Yes, I agree. "git diff origin/master" is a good idea.