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
