Bug in 'git log --remerge-diff' when used with '--find-object' and '--submodule=log|diff'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Elijah,

I found two bugs in '--remerge-diff' when combined with both '--find-object' and
'--submodule=log|diff'. I don't know if they have the same cause.

When using these flags together, *all* 2-parents merge commits are shown (even in a repo with
no submodule!)

Moreover, for merges with conflicted paths, all conflicted paths are shown as "(new submodule)",
even if they are not a submodule (in fact, even when no submodule is present
in the repository!).

This artificial example reproduces the bug:

```bash
#!/bin/bash

set -euEo pipefail

repo=repro
rm -rf $repo

TEST_AUTHOR_LOCALNAME=author
TEST_AUTHOR_DOMAIN=example.com
GIT_AUTHOR_EMAIL=${TEST_AUTHOR_LOCALNAME}@${TEST_AUTHOR_DOMAIN}
GIT_AUTHOR_NAME='A U Thor'
GIT_AUTHOR_DATE='1112354055 +0200'
TEST_COMMITTER_LOCALNAME=committer
TEST_COMMITTER_DOMAIN=example.com
GIT_COMMITTER_EMAIL=${TEST_COMMITTER_LOCALNAME}@${TEST_COMMITTER_DOMAIN}
GIT_COMMITTER_NAME='C O Mitter'
GIT_COMMITTER_DATE='1112354055 +0200'
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
export HOME=

git -c init.defaultBranch=unimportant init $repo
cd $repo
echo i>file
git add file
git commit -m file
git checkout -b side
echo s>>file2
git add file2
git commit -am side
git checkout -
echo m >>file
git commit -am main
git merge side -m clean
git checkout side
echo c>>file
git add file
git commit -am side2
git checkout -
echo cc>>file
git commit -am main2
git merge side || true
printf 'i\nm' > file
git commit -am conflicted
# look for a dummy object
git log --oneline --diff-merges=r --submodule=log --find-object=2c042ac4213768e55791098110d2ef2ef845881a
# same output with --submodule=diff
```

This is the output I get from the 'git log' call:

b4f1be9 (HEAD -> unimportant) conflicted
Submodule file 0000000...0000000 (new submodule)
a4ef223 clean

Notice both merges are shown despite none of them changing the number of occurences of 
2c042ac4213768e55791098110d2ef2ef845881a, which does not even exist in this repository,
and also that the conflicted merge shows 'file' as "new submodule".

Cheers,

Philippe.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux