Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Michael Albinus <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 28 May 2015 17:05:08 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> As a general tip. Next time you try to pull and find out someone
> >> already has already done what you just did, don't resolve the merge
> >> conflict. Instead, abort the merge with `git merge --abort` (this will
> >> get you back to the state you had right before the pull), and then
> >> locally revert your commit.
> >
> > I don't see how this advice will be able to keep Michael out of
> > trouble next time.  AFAICT, it will just get him in a different
> > situation, one that isn't simpler or safer to deal with.  Locally
> > reverting commits risks losing them, for example.
> 
> That's what I did, likely.
> 
> However, the tip might give me a way to bring the git repo back to a
> stable state, with potential loosing of local changes. As long as I'm
> not fluent in solving merge conflicts, that's good to know.

IMO, that's a misconception.  There's nothing "unstable" in having
conflicts or having a merge initiated by "git pull" be aborted due to
conflicts.  You can make safe changes from this situation, and you can
make unsafe changes from a reset tip (as it seems you did).

The procedure to resolve merge conflicts is simple: edit the
conflicted files, run "git add" on each one of them (VC should do this
automatically), make sure "git status" shows only staged files, and
then "git commit" all of them.  That's it.

And at any stage, you can always use "git status" and
"git diff origin/master" to show what still needs to be done to bring
your local clone in sync with upstream.

> > OTOH, merge conflicts are nothing to be afraid of, the procedure to
> > handle them is simple and straightforward.  Michael (and every one
> > else here) should IMO master that simple procedure, instead of
> > avoiding it.
> >
> > In a dVCS, you cannot rely on being able to avoid merges all the time
> > anyway.  There are always races with other developers.
> 
> If git would be more friendly to tell what happens ...

It will be more helpful if you use "git status" more frequently.

> why the hell I must take care on files I've never touched myself.

You don't.  You just need to commit them after all conflicts have been
resolved.