Re: VC mode and git

[martin rudalics]

>> (1) Say that a pull is a fetch plus a merge and what these do.
>
> Why would that matter for people who just want to copy their mental
> models from CVS to Git with minimal changes?

According to this thread there are people who recommend to never pull
but always do fetch and merge instead.  We should say whether they are
right.  And we probably should tell what happened after git pull with
the following


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.

> Every VCS does some kind of a fetch and a merge when it pulls.  Git
> and AFAIK also Mercurial are unique in that they let the user invoke
> each of these separately.  But IMO that only matters if we then
> explain how to use these separate steps to the user's benefit, and I
> don't see how doing so is possible, let alone necessary, within a
> CVS-like workflow.

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.
Well, I wouldn't know even without that message ...

> Maybe I'm missing something, so please elaborate why you thought this
> to be beneficial.
>
>> (2) Distinguish the two ways a merge can fail: The one where git refuses
>>       to merge because it would overwrite changes and the second one where
>>       it detects conflicts.  And how to deal with them.
>
> I think the way to deal with both is the same,

In the one case I get the message cited above.  In the other case I get
conflicts and git asks me to resolve them.

> and that's what the
> instructions describe.  Again, maybe I'm mistaken, but then please
> show an example where the instructions would fail in one of those
> cases.
>
> The intent is to try to preserve the CVS mental models, so the
> description generally follows what one would do with conflicts created
> by "cvs update", the only changes being those that are strictly
> necessary with Git.

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)


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

>> (3) Mention both stashing and rebasing.  IMO it's no use ignoring them.
>>       People will find them in the manuals and tutorials and we should at
>>       least tell them why the method we propose here is sufficient or
>>       better.
>
> The fact that these are mentioned in the manuals is not a good
> guidance for mentioning them, since the manuals mention a lot more
> than just these two.
>
> Stashing was not mentioned there to begin with; it isn't even
> mentioned in the more advanced GitForEmacsDevs page, nor was its bzr
> equivalent ever mentioned in the instructions we wrote for Bazaar.
> CVS has no equivalent for stashing.  So I'm not sure why you think it
> should be mentioned.  Perhaps the reason is that you yourself use it a
> lot.  Once again, please elaborate.

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.

> Rebasing is a tricky issue.  Richard asked (off-line) for an
> explanation of what it is, so the notion itself is not immediately
> clear to everyone, and would need to be explained.  Next, we decided
> not to recommend rebasing (because we merge from the release branch,
> and generally prefer merge-based workflows), so if we want the readers
> of those instructions to use rebase, we must describe it as a marginal
> feature for rare situations.  Is it worth that, and if so, why?

I never used rebasing and can't tell whether it's of any use.  But it is
propsed in GitForEmacsDevs and it's very confusing if we have two texts
with a similar purpose proposing different things.

> It is possible that both of these issues could be explained in a
> separate section near the end of the page, as some additional stuff
> worth learning.  But then (a) we should think carefully how we would
> like to categorize them, and (b) there's a real danger people won't
> read something that has no direct bearing on the otherwise
> cookbook-like approach of the instructions.

If the cookbook instructions are fail-safe there's no problem.  I'm
afraid they aren't.

> Those are my thoughts, feel free to point out where I'm wrong.
>
> Thanks.

Thank you for working on this.  I'm afraid it's no real fun.

martin