Re: VC mode and git

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <address@hidden>

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

No, I am sure that at some point he pulled when fully committed, from
trying the experiments.

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

Thank you for the courtesy.

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

OK, so I interpreted this as

1. Hack the "some changes" mentioned above.
2. Git pull successfully, implying the files changed in Richard's
   workspace but (I assume) not committed did not conflict.
3. Edit ChangeLog and C-x v v to commit, successfully.

   But some log messages were missing.  (This makes no sense to me,
   unless somehow he did not see messages that said that the merge was
   not performed.  Is it possible that vc displays messages from
   stdout but not stderr or something like that?  I'm grasping at
   straws, I know -- but Richard is a good bug reporter, and yet what
   he reports doesn't make sense.)

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

If the previous pull succeeded, does this mean that he lost a race in
a handful of minutes?  And lost "a lot" of text?  Weird.

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

Confirmation that there were uncommitted files throughout.  But wait!
the plot thickens:

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

Aha!  But "git commit --include lisp/ChangeLog" DTRTs in this case,
committing the staged changes from the files successfully merged as
well as the new changes from the files where conflicts were resolved.
(Tested in a toy repo.)

In other words, *Emacs* screwed Richard, not git.  git, with a little
scripting (either in the shell or in vc.el) may very well be quite
capable of supporting Richard's (and Alan's!) preferred "leave the
changes still being tested uncommitted" workflow.

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

I don't think "git commit" will actually work.  "git commit" alone
will either commit only the unconflicted staged files (I think this
unlikely) or will refuse to commit because it remembers that ChangeLog
was conflicted (more likely).  You need to "git add lisp/ChangeLog",
or you use --include on the command line (note that in this situation
"git commit lisp/ChangeLog" and "git commit --only lisp/ChangeLog" are
equivalent according to the manual).

Perhaps v in vc-dir might do the right thing, but I suspect it suffers
from the same issue as "git commit" with no file arguments.

 > It would be good if "C-x v v" tried to support this situation
 > better.

Definitely.  Unfortunately it's late and I can't guess whether
"--include" is generally appropriate, or whether there's a more
frequent case where "--only" is appropriate, and "--only" should get
precedence.  I hope Eric knows.