Re: git pull fails with merge conflicts. How can this possibly happen?

[Alan Mackenzie]

Hello, David.

On Fri, Nov 14, 2014 at 11:01:15AM -0800, David Caldwell wrote:
> On 11/14/14 10:37 AM, Alan Mackenzie wrote:
> > I've now advanced from my last puzzlement.  It turns out that "git
> > clone" doesn't properly initialise the new repository.  I had to do this
> > manually with "git checkout emacs-24".

> Git checkout looks for a branch with the name "emacs-24", failing that
> it looks for one matching that in your remotes/* and copies that branch
> into "emacs-24". Thus remotes/origin/emacs-24 should be copied to
> emacs-24 (and you can check this in the .git/refs/* directory tree +
> .git/packed-refs file—it's all text).

How come "git clone" didn't work properly?  Surely the branch structure
in the original and the copy repositories should be identical.  That's
what "cloning" means.

What exactly is this "remotes/*".  When you talk about "copies that
branch into "emacs-24"", is this copying within the repository, or from
another repository into this one.  Where is this described?

> > This "git pull" leaves a mass of merge conflicts.  How can this be?
> > What does git pull actually do?  The git pull man page says:

> >   "Incorporates changes from a remote repository into the current
> >    branch. In its default mode, git pull is shorthand for git fetch
> >    followed by git merge FETCH_HEAD."

> The man page is correct.

:-)

> >   address@hidden ~/emacs/emacs.git/emacs-24 $ git branch -a
> >   * emacs-24
> >     master
> >     remotes/origin/HEAD -> origin/master
> >     remotes/origin/emacs-24
> >     remotes/origin/master
> >   address@hidden ~/emacs/emacs.git/emacs-24 $ git pull

I notic here that "emacs-24" has the *, but "remotes/origin/HEAD" ->
"origin/master".  Could this have something to do with my failed git
pull?  Unfortunately, only the syntax of "remotes" is described in the
git glossary, not its semantics.

> This is the "git fetch" part of "git pull":

> >   remote: Counting objects: 32, done.
> >   remote: Compressing objects: 100% (16/16), done.
> >   remote: Total 32 (delta 26), reused 22 (delta 16)
> >   Unpacking objects: 100% (32/32), done.
> >   From /home/acm/emacs/emacs.git/master/.

> This is the "git merge" part:

> >    + 911ad4a...6688117 emacs-24   -> origin/emacs-24  (forced update)

> The problem is the 911ad4a. If you look at that commit it is on the
> master branch. This implies that your local emacs-24 branch was not
> *really* the emacs-24 branch (Maybe you accidentally did "git checkout
> -b emacs-24"?).

I don't think I did, but anything's possible.

> Git matched the "emacs-24" name to the "origin/emacs-24" and merged that
> in, but since your emacs-24 branch was was really just master you got a
> bunch of merge conflicts.

> That is my guess anyway, it's hard to tell without seeing your repo. If
> you "git reset" then "git log", which commit is first? If it's the
> 911ad4a then you aren't really on the emacs-24 branch.

It's too late at night to start trying to make sense of the git reset man
page.  I'll have a look at that tomorrow.

> You can try poking around with gitk to see how the branches interact. I
> also quite like the "tig" tool (not part of git)—it's sort of a curses
> version of gitk.

gitk doesn't work on my system, of course.  (Nothing ever does without a
lot of effort).  Funny thing: looking at the gitk man page, there doesn't
appear to be a way of specifying the repository.  Hmm.

> -David

-- 
Alan Mackenzie (Nuremberg, Germany).