Re: VC mode and git

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

Eli Zaretskii writes:

 > > Richard will speak for himself about the size of the price, but I
 > > suspect he doesn't need to pay it at all in the current case (see my
 > > other post, specifically about "git commit --include"
 > 
 > Maybe I'm missing something, but I don't understand how --include
 > could have helped in this case.

Well, as you wrote elsewhere, if he's using VC there's a save-hook (in
smerge-mode?) that automatically adds the file whose conflicts are
fixed, and --include is a no-op.

 > So AFAIU "git commit --include FILE" is equivalent to these two
 > commands:
 > 
 >    git add FILE
 >    git commit

Yes.  That's how I understand the man page, too, and it corresponds to
the experiments I did.

 > If this is true, then this will commit both the file with conflicting
 > uncommitted changes and the rest of the stuff fetched from
 > upstream.

True.

 > So how is it different from what I described on the Wiki?  The result
 > is the same: the changes that were left uncommitted because they are
 > "not ready" will end up committed.  My procedure is IMO better in that
 > it doesn't require any non-default switches to commands.

Probably it isn't any different.  It's just that I was unclear on what
was going to be committed.

In fact, as long as the developer restricts himself to committing
merged files (including but not limited to those with resolved
conflicts) it's possible it's exacty what Richard wants: leave the
files containing changes needing further testing uncommitted.  But:

 > > He will need to do something else in the case that he runs into the
 > > "will overwrite your changes" message.
 > 
 > But that's exactly the situation I thought we were discussing:
 > uncommitted changes that conflict with changes upstream.  So now I'm
 > confused about the use case you referred to above.

But I'm trying to look at this from Richard's point of view int he
current situation.  As far as I can tell that's not the case in
Richard's current workspace, except for lisp/ChangeLog, and that's
already a special case in his workflow since he didn't write it up
until after he did the pull (but did do the code changes before the
pull).  It's also a special case in Emacs, since the ChangeLog update
actually belongs to the merge in some sense.

 > > However, since he seems comfortable with the "don't touch
 > > ChangeLogs until after you pull" workflow, I'm guessing the
 > > probability that he'll run into something really ugly is
 > > unlikely.
 > 
 > Agreed, and that's why I think stash could be avoided.

Unfortunately, there's the case that hasn't been mentioned explicitly,
which is where he has a code change that touches multiple files, some
of which are conflicted and some of which are not.  The conflicted
files have to be committed to keep git happy unless you do some
"advanced" stuff, such as stash.  I don't think you really want
Richard's changes mixed with merge changes.