Re: VC mode and git

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

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" -- and now you
have a hint as to why manipulating the "index" is useful[1]).

He will need to do something else in the case that he runs into the
"will overwrite your changes" message.  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.

True, this time he actually committed "offline" twice because of
missing pushes which could cause issues (maybe those commits are the
missing logs?), but if he finds a good way to automate those, he
should be in pretty good shape.

Footnotes: 
[1]  Unfortunately it still doesn't help with the "atomic check-in"
issue but perhaps that can be solved to Richard's satisfaction with
the proposed post-commit hook.