Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Richard Stallman <rms@gnu.org>,
>     rudalics@gmx.at,
>     sorganov@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 05 Apr 2015 17:44:49 +0900
> 
> Eli Zaretskii writes:
> 
>  > > If the uncommitted files were inadvertant (typical beginner
>  > > mistake), your advice to commit, pull again, and fix the conflicts
>  > > is appropriate.  But this doesn't work for Richard, who deliberately
>  > > leaves some changes uncommitted.
>  > 
>  > Why doesn't it work?  Because changes he didn't want to commit just
>  > yet will end up committed?  I think this is a small price to pay for
>  > avoiding to learn about stashing, and for having what is mostly the
>  > same workflow he and others had with CVS.
> 
> 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.  The man page says:

  --include 
    Before making a commit out of staged contents so far, stage the
    contents of paths given on the command line as well.

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

   git add FILE
   git commit

If this is true, then this will commit both the file with conflicting
uncommitted changes and the rest of the stuff fetched from upstream.
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.

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

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