[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v4 04/24] merge-recursive: provide a better label for diff3 common ancestor
From:       Jeff King <peff () peff ! net>
Date:       2019-09-30 21:19:09
Message-ID: 20190930211909.GA29232 () sigill ! intra ! peff ! net
[Download RAW message or body]

On Mon, Sep 30, 2019 at 05:14:37PM -0400, Jeff King wrote:

> > This chosen label was perfectly reasonable when recursiveness kicks in,
> > i.e. when there are multiple merge bases.  (I can't think of a better
> > label in such cases.)  But it is actually somewhat misleading when there
> > is a unique merge base or no merge base.  Change this based on the
> > number of merge bases:
> >     >=2: "merged common ancestors"
> >     1:   <abbreviated commit hash>
> >     0:   "<empty tree>"
> 
> I got a funny result from this today while rebasing some patches in
> git.git, where the base is reported as "00000000". I didn't make a
> minimal case, but you can easily reproduce it with:
> 
>   cd /your/git/clone
>   git fetch https://github.com/peff/git odd-diff3-base
>   git checkout -b odd-diff3-base FETCH_HEAD
>   git -c merge.conflictstyle=diff3 rebase --onto origin/master HEAD~2
> 
> Maybe this has to do with "git apply --build-fake-ancestor" being used
> under the hood?

Oh, indeed, this seems to be the case for all rebases. Doing:

  git init repo && cd repo
  
  echo base >file && git add file && git commit -m base
  echo master >file && git commit -am master
  git checkout -b side HEAD^
  echo side >file && git commit -am side
  git config merge.conflictstyle diff3
  
  git rebase master

yields:

  <<<<<<< HEAD
  master
  ||||||| 0000000
  base
  =======
  side
  >>>>>>> side

-Peff
[prev in list] [next in list] [prev in thread] [next in thread]