Take the 2-minute tour ×

I understand that the "ours" merge strategy (hear the quotes around merge?) actually does not use any commits from the other branch.

The "ours" strategy is sometimes mentioned as "keeping the other's history". But it records that history as "applied". Weird. Are there cases where I do want this behaviour?

As an alternative, you could just as well import the other branch and let its history there, where it belongs.

Note that I am asking about the "-s ours" strategy, not the "-X ours" option to "-s recursive" (which is different in that it applies those commits that don't conflict).

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

One use is to "skip" a commit made on a maintenance branch that isn't intended to go back into your main/trunk branch of development. See this previous question for an example: git - skipping specific commits when merging

share|improve this answer
add comment

I'm using this pseudo-merge in an additional branch used to track the other branches, including abandoned ones. This additional branch has in fact only one file (called branches-list), which contains a text list of the active and inactive branches, but at the important points (mostly branch-points and "end-of-branch", either merge or abandon) the development branches are merged (with "-s ours") to this branch.

Here a recent screenshot of our project:


Thus, I lastly branched elo-test from master, and then from this I branched stroke-transform-example for my question here (and the answer - this should have been two different commits, though). At each such branch-point, and more importantly, at each point when a branch ends without it being merged to some other branch (which will happen to stroke-transform-example when I next clean up), I now merge this branch with -s ours to the meta-branch branches.

Then I can later delete the not-used-anymore branches without losing their history, so the output of git branch -a is always quite small. If I then ever want to look back at what I did then, I can easily find them.

(I think this is not really what this option is made for, but it works quite nice.)

share|improve this answer
Thank you for your illustrative answer. After *merge -sours", discriminating this "pseudo" merge from "real merges" requires looking at the diff, am I getting this right? –  Prestel Nué Feb 22 '11 at 14:41
btw&ot, I think I will try this link occasionally (with paper&pencil)! –  Prestel Nué Feb 22 '11 at 14:43
Yes, you are right. In my case I'm using these pseudo merges only on the branches branch, so it is easy to see. -- This game is much easier to play with computer support, since you shouldn't see the hidden points of your contrahent. Feel free to look at our program, it is free to play online :-) –  Paŭlo Ebermann Feb 22 '11 at 14:47
add comment

Your Answer


