GIT: What is commits priority during merge?

Question

I wonder, what is the priority of picking commits during merge in the situation, described below.

I have develop branch.

D1 - D2 - D3

Then I created release branch from it and add some commits.

D1 - D2 - D3 - R4 - R5

In the meantime some commits to develop were added

D1 - D2 - D3 - D6

Then, I remove some commits from release branch using git rebase -i HEAD~3:

D1 - x - x - R4 - R5

---

How release branch will be merged to develop using git merge --no-ff release? I want to have it like this:

D1 - D2 - D3 - R4 - R5 - D6

And is there a possibility that I'll get merged branch with commits deletion?

D1 - x - x - R4 - R5 - D6

I am looking forward for explanations about "behind the scene" :)

Answer 1

If you did a revert in release it would revert those commits on a merge. If you did a rebase it won't. That's because revert shows you explicitly deleting them, and retaining that fact in the history. rebase makes it look like those commits never happened in release, so there's no reason for the merge to delete them.

As far as priority, both branches have equal priority no matter what. Going back to the last commit the branches have in common, if each branch changes something in different ways, git will show it as a merge conflict. The only reason the rebase doesn't revert those commits is because you rewrote history to make it look like they were never present in the branch to begin with.

As an aside, you do realize you can test these things out in git, either in a clone or by being careful with your branches, in probably less time than it takes to ask a question?

Answer 2

As an addition to the other answers:

I wonder, what is the priority of picking commits during merge in the situation

Git normally does not have the notion of "priority" during merges. During a merge, all branches are equally important, and Git tries to combine the changes from all branches.

If there is a contradiction (such as different branches changing the same line in different ways), Git will not somehow let one branch "win", but will report a merge conflict.

This was actually a deliberate design decision. Linux talking about merging in Git:

Linus: Me personally, I want to have something that is very repeatable and non-clever. Something I understand or tells me that it can't do it.

http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php

So Git deliberately does not somehow cleverly try to figure out which branch is "more important" - it just leaves the decision to the user.