Suppose I am rebasing experiment branch on master and there are conflicts in files. And of course there are files deleted in both branches. So when I am resolving the conflicts, in git status
I see deleted by us
and deleted by them
. Its very confusing. Is there any way of understanding what they mean? Who is them and who is us?
Or while rebasing is there another way to know which file was deleted by which branch? Like printing the branch name?
'deleted by us' means the file is deleted in the commit which you are trying to do a cherry-pick. It is not file is deleted by you. Git tells that the file was deleted in some other commit, and allows you to decide to retain it (git add) or to remove it. You can do git cherry-pick --continue once you sort this out.
When you rebase, us refers the upstream branch, and them is the branch you're moving about. It's a bit counter-intuitive in case of a rebase. The reason is that Git uses the same merge-engine for rebase, and it's actually cherry-picking your stuff into the upstream branch.
Rebasing a branch on another "re-applies" (fairly smartly, these days) the commits of the currently checked out branch on top of the tip of the target. So, yes, if you do it over and over again then you will keep your current branch up to date.
Note that a rebase merge works by replaying each commit from the working branch on top of the
<upstream>
branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with<upstream>
, and theirs is the working branch. In other words, the sides are swapped.
https://git-scm.com/docs/git-rebase/2.17.0 (latest: https://git-scm.com/docs/git-rebase)
Hence, files "deleted by us" are those that were deleted on the branch you are rebasing onto (the final branch), and files "deleted by them" are files that were deleted in the branch you are rebasing (the one that will be dropped).
$ ls a $ git log --oneline --graph --decorate --all * d055cdd (HEAD -> y) Write baz in a-file | * 487dc8c (x) Write bar in a-file |/ * 3fa0da5 (master) Write foo in a-file $ git rebase x First, rewinding head to replay your work on top of it... Applying: Write baz in a-file Using index info to reconstruct a base tree... M a Falling back to patching base and 3-way merge... Auto-merging a CONFLICT (content): Merge conflict in a error: Failed to merge in the changes. Patch failed at 0001 Write baz in a-file The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". $ cat a <<<<<<< HEAD bar ======= baz >>>>>>> Write baz in a-file $ git checkout --ours a $ cat a bar $ git checkout --theirs a $ cat a baz
AFAIK there is no switch to display the specific names of the branches explicitly with the official tools. Unless I'm wrong this is just one of those things you need to learn to get through the initial confusion.
To their credit, it does make a lot of sense if you think about it.
The text of the manual page is a little ambiguous as it could be interpreted to be relevant only when using the --merge
option. This is exacerbated by a second mention of the behavior in --strategy
: "Note the reversal of ours and theirs as noted above for the -m option.".
However, I believe this is not contrasting the behavior of git-rebase when --merge
is used with when it isn't; rather I believe it is contrasting the behavior of git-rebase with git-merge. The MERGE STRATEGIES section is clearly ripped from the git-merge manual page, so it's somewhat easy to imagine that the author felt the need to emphasize the swap when using rebase since it's not mentioned in that section. The following sentence, to me, confirms this interpretation: "[...] git rebase replays each commit from the working branch on top of the branch using the given strategy [...]".
Although we now understand that the merge strategy should have no impact on the sides (only the choice of git-merge vs git-rebase should), I'll note --merge
is implied by the default strategy regardless (making the default behavior completely non-ambiguous).
Below is a copy of SzG's answer on a similar question:
When you merge,
us
refers to the branch you're merging into, as opposed tothem
, the branch to be merged.When you rebase,
us
refers the upstream branch, andthem
is the branch you're moving about. It's a bit counter-intuitive in case of a rebase.The reason is that git uses the same merge-engine for rebase, and it's actually cherry-picking your stuff into the upstream branch.
us
= into,them
= from.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With