19

After a git rebase I have merge conflicts to solve. I'm confused by the meaning of "added by us" on A.java. What prevents it being automatically added/staged as a new file like C.java?

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   com/company/C.java

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        added by us:     com/company/A.java
        both modified:   com/company/B.java

git version 2.5.1.windows.1

chrisjleu
  • 4,329
  • 7
  • 42
  • 55
  • It sounds like you're aware that rebase works by repeated cherry-pick, and that these cherry-pick operations are done while growing an anonymous branch off the `--onto` target of the rebase. Hence "added by us" means "are present in our current detached-HEAD commit as compared vs the merge-base". It does seem odd/wrong that this is not automatically staged for commit. – torek Jun 01 '16 at 09:39
  • Could you solve the mystery? – Robert Siemer Dec 27 '16 at 17:32
  • 2
    This question got a far better answer than you got - it helped me: https://stackoverflow.com/questions/21025314/who-is-us-and-who-is-them-according-to-git/63911630 – killthrush Aug 22 '21 at 13:47

1 Answers1

3

"git rebase" is clunky and obtuse, but oh so useful. To summarize what I think is going on in your case, a rebase "merge conflict" is produced by the "both modified". You have to pick which mod you want - the "com/company/B.java" mods on their branch, the mods on your branch or some combo of both. The "added by us:" is telling you that "com/company/A.java" is new to your branch and was brought in by the branch you're rebasing against. But due to the way git implements rebase, "us" is really their branch. Not sure if this is counted as a rebase "merge conflict" unless you deleted "com/company/A.java" on your branch, the target of the rebase. In that case, that would be a rebase "merge conflict" that you would have to solve. To resolve such a "merge conflict," remember "us" is really their branch and "theirs" is really your branch. Blah.

BoiseBaked
  • 792
  • 7
  • 15
  • I should mention this. Sometimes "git rebase" just screws up a cherry-pick and you have to skip it by doing `git rebase --skip`. – BoiseBaked Mar 11 '17 at 00:27