Re: VC mode and git

[Steinar Bang <sb@dod.no>]

>>>>> martin rudalics <rudalics@gmx.at>:

> error: Your local changes to the following files would be overwritten by merge:
> ...
> Please, commit your changes or stash them before you can merge.
> Aborting


> AFAICT this signlas a succeeding fetch and a failing merge.

Not exactly, it signals a succeding fetch, and no merge done

> IIUC git's pull is not atomic.  When the merge fails with a message like
> the above I have no idea in what state my copy of a repository is in.

It is in the same state it was as before you did the pull.

> Well, I wouldn't know even without that message ...
[snip!]
> In the one case I get the message cited above.  In the other case I get
> conflicts and git asks me to resolve them.

Now, _if_ you have modified uncommitted changes, _and_ get conflicts,
then things get slightly worse.

The conflicts will not be in any of your locally modified files, because
those haven't been touched by the merge (if they were, the merge
wouldn't have started).

> Now suppose that, in reaction to the message above I do

> git commit -a
> git pull

> and now am told to resolve my conflicts.  I do that via smerge-mode,
> save the file(s) which had the conflict(s) and do

> git commit

> as recommended.  I tried that just now with a conflict in Changelog.
> After this git told me that

> On branch master
> Your branch and 'origin/master' have diverged,
> and have 2 and 74 different commits each, respectively.
>   (use "git pull" to merge the remote branch into yours)

> All conflicts fixed but you are still merging.
>   (use "git commit" to conclude merge)

This message means your merge wasn't completed.  What did
 git commit
say?  Were there more files than the ChangeLog that needed merging?

Didn't smerge-mode automatically stage the conflict-fixed file for
commit?  (didn't you remove all conflict markers?)

> and, after the recommended git pull

> CONFLICT (content): Merge conflict in lisp/ChangeLog
> Automatic merge failed; fix conflicts and then commit the result.

> just that I did not find any conflicts at this stage.

You mean no conflict markers in the ChangeLog?  Did you try diffing
ChangeLog against orgin/master to see if there were changes and if they
looked sensible?

Did you try staging ChangeLog manually for commit?
 git add ChangeLog

> So I practically ended up in an infinite loop which I was able to
> break only via a hard reset.  I suppose this is similar if not identic
> to Richard's original problem which is apparently very easily
> reproducible here.

A hard reset sounded a bit drastic.

Did you have changes in the ChangeLog that were yours? Or was the
conflict purely caused by git?

> Stashing is offered in the first git message cited above.  If it's bad
> we should tell people why.  OTOH I never had a problem with stashing
> and in particular it never got me into the loop I mentioned later.

The reason to stay away from stash from this workflow, is that it is yet
another concept to relate to.

The fact that "git stash pop" can result in a conflict that needs to be
resolved and seemingly needs to be committed (it doesn't), is a
complicating factor for a simple CVS-like workflow.