0

I have two branches version-1.0 and version-2.0, their common ancestor is commit C.

I try to merge the two branch and it shows a file a.txt conflicted.

for example:

$ git checkout version-2.0
$ git merge version-1.0
$ git status 
Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
    deleted by them: a.txt

$ git ls-files -u | grep a.txt
100644 xxxxxxxxxxxxxxxxxx 1       a.txt
100644 yyyyyyyyyyyyyyyyyy 2       a.txt

$ git --version    # The git enviroment
git version 2.34.1.windows.1

I get common ancestor commit C from this command: git merge-base version-1.0 version-2.0.

But git diff --stat C version-1.0 didn't show any change of a.txt file.

How does Git make this file conflicted?

How to get more details when Git Merge two branch?

Thanks for your answer!

Adooo
  • 640
  • 6
  • 22
  • Does `git rev-parse C:a.txt version-1.0:a.txt` list the same SHA1 twice? Or do you get error `fatal: path 'a.txt' does not exist in 'version-1.0'`. – j6t Jul 07 '22 at 11:58
  • 1
    "How does Git make this file conflicted?" Well, the message from Git tells you the answer. One side edited this file, but the other side deleted the file. That's a conflict. – matt Jul 07 '22 at 12:34
  • 1
    @matt I think OP's question is not about the conflict, but instead this: "But `git diff --stat C version-1.0` didn't show any change of a.txt file." – TTT Jul 07 '22 at 14:40
  • @TTT that is why my answer shows a `git diff` that gives the expected output. – matt Jul 07 '22 at 14:41
  • @matt other than `--compact-summary` vs `--stat`, I can't tell if your diff command is different than what OP did. – TTT Jul 07 '22 at 14:44
  • My gut feeling is what OP did should have worked, so maybe OP didn't do *exactly* as described? – TTT Jul 07 '22 at 14:53
  • 1
    @TTT I don't necessarily believe anything I'm told, so perhaps the OP's "C" is not really the merge base, or the OP's `diff` command specifies it incorrectly. In my formulation, the diff is _certainly_ with the merge base. – matt Jul 07 '22 at 15:22
  • @j6t it both get same result like this: `fatal: path 'a.txt' exists on disk, but not in 'version-1.0' version-1.0:a.txt` – Adooo Jul 07 '22 at 16:16
  • 1
    It maybe the bug of `git version 2.34.1.windows.1`. Because I tried the same merge in WSL(ubuntu 20.04) enviroment with `git version 2.25.1`, the result have no conflict file `a.txt`, it's correct! – Adooo Jul 07 '22 at 17:13

1 Answers1

1

The git status output you provide is exactly what you may expect to see when one side of an attempted merge deletes a file but the other side edits the same file.

I'll give a toy example. We start with this situation:

* e9f73e4 (mybranch) deleted C
| * fb8c1ca (HEAD -> main) edited C
|/  
* c54f4a6 C
* 0e1d397 B
* 38615b3 A

We are on main. We attempt to merge mybranch, and we get a merge conflict, with exactly the status you provided:

% git switch main
% git merge mybranch
% git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
    deleted by them: C

no changes added to commit (use "git add" and/or "git commit -a")

To see what happened, compare the merge-base to "them" (mybranch), using the compact-summary option to give a nice clear output:

% git diff --compact-summary $(git merge-base main mybranch) mybranch
 C (gone) | 1 -
 1 file changed, 1 deletion(-)

To resolve the conflict, either git add or git rm the affected file, and then say git merge --continue. Let's say I agree with "them":

% git rm C
rm 'C'
% git merge --continue
[main d19f36b] Merge branch 'mybranch'

The merge succeeds and life goes on.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • But the output of `git diff --compact-summary $(git merge-base version-1.0 version-2.0) version-1.0 | grep a.txt` is also emtpy in my situation. – Adooo Jul 07 '22 at 16:30
  • @Alex: if the two hash IDs `xxxxxxxxxxxxxxxxxx` and `yyyyyyyyyyyyyyyyyy` differ, the contents of the two files (in merge base and HEAD commits) differ. You can view the contents directly with `git show :1:a.txt` and `git show :2:a.txt`. – torek Jul 08 '22 at 00:19
  • It's possible (just one *possibility*, I'm not saying this is the case here) that `git merge-base` is finding *a* merge base, but there are in fact multiple merge bases, so that `git merge -s ort` or `git merge -s recursive` (these are the defaults depending on Git version) first merge the merge bases. In this case you may see a merge conflict in the merge-base version in `:1:a.txt`. – torek Jul 08 '22 at 00:21