Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

git rebase "deleted by us" and "deleted by them" [duplicate]

Tags:

git

git-rebase

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?

like image 763
Milind Dumbare Avatar asked Dec 11 '14 10:12

Milind Dumbare


People also ask

How do you resolve deleted by US conflict?

'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.

Who is us and them in git rebase?

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.

What happens if I rebase twice?

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.


2 Answers

Reference documentation

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).

Demonstration

$ 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.

More pedantic analysis

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).

like image 68
tne Avatar answered Sep 18 '22 21:09

tne


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 to them, the branch to be merged.

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. us = into, them = from.

like image 31
Maxim Suslov Avatar answered Sep 20 '22 21:09

Maxim Suslov