Re: VC mode and git

[Eli Zaretskii]

> Date: Sat, 04 Apr 2015 17:59:45 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
>  >> (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.

I don't think such a discussion belongs to that page.  Those are
cookbook style instructions, so discussing things not directly
referenced in the instructions should be avoided.

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

Yes, and I already added that, please take another look.

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

I tried to explain that in the latest changes.

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

Right, so they are both described now.

>  > 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 don't see this infinite loop (I tried with 2 local repositories
instead).  After the second commit, a pull says "already up-to-date".
Not sure why the difference.

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

I'd like to avoid additional commands, if possible.  So I describe how
to solve the conflicts by committing local changes in the files that
prevented the merge.

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

I think we should remove rebasing from that page as well.  It is there
because we originally thought "pull --rebase" was a good idea.  That
was before we understood the damage it could cause in an otherwise
merge-based workflow, including what gitmerge.el does when it merges
from the release branch.

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

I don't play with Git for fun.