0

In Git in master-branch I have these files:

foo1.txt
foo2.txt
bar1.txt
bar.txt

Then I create branch A and modify files foo1.txt and foo2.txt. After this I go back to master-branch and create branch B in which I modify files bar1.txt and foo1.txt. Please note that foo1.txt is the only file, which is modified by both branches A and B.

Now I would like to get a list of files, which were modified by branches A and B. This would be very helpful to check for any conflicts before I merge branch A into branch B .

I tried this, but this give me only the differences between branch A and B:

git diff A B --name-only

bar1.txt
foo1.txt
foo2.txt

How can I get get a list of files, which were modified by branches A and B ? The expected list has the only entry foo1.txt

Rachid K.
  • 4,490
  • 3
  • 11
  • 30
Aedvald Tseh
  • 1,757
  • 16
  • 31

1 Answers1

2

One way to do this would be to use comm and the diff 3 dot syntax:

comm -12 <(git diff A...B --name-only | sort) <(git diff B...A --name-only | sort)

comm -12 only shows the items that appear in both lists.

cmbuckley
  • 40,217
  • 9
  • 77
  • 91
  • 1
    At first glance I think this will also show all new stuff on `master` if it moves ahead from where `A` and `B` branched off of it. To fix that you could use the merge-base, which is also achieved by the 3 dot syntax. So, perhaps change both of your diff commands to not use `master`, and then use: `A...B` and `B...A`. (Untested but I think that should nail it...) – TTT Sep 16 '22 at 16:26
  • Also, probably want to mention this requires *nix shell. Also, I think diff already sorts for you, so that may not be necessary. – TTT Sep 16 '22 at 16:26
  • Good point about triple-dot notation. diff doesn’t sort the output and comm will complain if the lists aren’t sorted, hence adding it in here. – cmbuckley Sep 16 '22 at 17:22
  • Are you sure `diff --name-only` doesn't sort the output? I just compared a large diff that had more than 3000 files and the result with and without sort was identical. – TTT Sep 16 '22 at 17:32
  • FYI, I just noticed your edit also included a link to 3 dots with `log`, but that's different than 3 dots with `diff`. (I fixed it.) Here's a [summary of the differences](https://stackoverflow.com/a/69559520/184546). – TTT Sep 16 '22 at 19:25
  • 1
    Thanks again. I was aiming for something in the “specifying revisions” section of the original docs, but it doesn’t look like the 3-dot notation is specifically documented in there. – cmbuckley Sep 16 '22 at 21:08
  • Regarding ordering, did you test this with upper-case file names? The output of `git diff --name-only` will put e.g. *README.md* before *index.html*, and `comm` will complain about that. – cmbuckley Sep 16 '22 at 21:21
  • Interesting. I *do* have some of those with caps in my list, and `sort` *also* displays them first, and `comm` is cool with it. I just tried `sort -f`, which would give the order your `comm` is looking for, and then I got the error. I'm using the default settings for Git Bash on Windows; perhaps `comm` is using the same collate settings too, and it can differ per system. – TTT Sep 16 '22 at 21:43
  • 1
    Regarding my last comment, I guess the good news is, since having `sort` there helped you, and didn't hurt me, it's probably best to leave it as the most general solution. ;) – TTT Sep 16 '22 at 22:04
  • It seems that comm does not support file redirects with `<` and evaluations with `(`. I receive errors `bash: syntax error near unexpected token (` and `comm: missing operand`. I checked several documentations on the web for `comm` and neither the usage of `<` and `(` is shown. I am using cygwin (MINGW64_NT-10.0-19044). – Aedvald Tseh Sep 19 '22 at 06:14
  • It’s not comm that doesn’t support process substitution - that’s likely the version of bash that’s causing your problem. – cmbuckley Sep 19 '22 at 10:27
  • 2
    @AedvaldTseh the problem might [actually be cygwin](https://stackoverflow.com/questions/48137533/syntax-error-near-unexpected-token-comm-2-3-sort-path-file1-sort-path#comment83255453_48137533). – TTT Sep 19 '22 at 17:29