3

I want to go from this

A - B - C - D - E - F - G 

where Branch1 is pointing at E and Branch2 is pointing at G

to this:

Branch1:    A - B - C - D - E
                     \
Branch2:              F - G

And I want Branch2 to always 'win', I've got as far as this:

git rebase -s recursive -X theirs --onto C Branch1 Branch2

That works fine - except that rebase chokes on binary files - saying it can't merge them. How do I go about telling git that I don't want to merge them, I just want to take 'theirs' each time?

Benjol
  • 63,995
  • 54
  • 186
  • 268
  • 1
    @Victor, I mean that if there are any conflicts, instead of asking me to resolve them, git will take whatever is in Branch2. – Benjol Dec 23 '10 at 07:34

2 Answers2

0

The following is a shot in the dark:

From the git-rebase documentation:

   -m, --merge
       Use merging strategies to rebase. When the recursive (default)
       merge strategy is used, this allows rebase to be aware of renames
       on the upstream side.

       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.

   -X <strategy-option>, --strategy-option=<strategy-option>
       Pass the <strategy-option> through to the merge strategy. This
       implies --merge and, if no strategy has been specified, -s
       recursive. Note the reversal of ours and theirs as noted in above
       for the -m option.

If -X implies --merge, and --merge swaps theirs and ours, maybe that's the problem. What happens if you switch theirs for ours?

Victor Zamanian
  • 3,100
  • 24
  • 31
  • 1
    From what I have understood ([here](http://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote)), when rebasing, 'ours' and 'theirs' get switched, so in the context of my question, ours is the branch I'm rebasing onto (Branch1), and theirs is the branch I'm rebasing (Branch2). In this case, it is actually `theirs` that I want to preserve. – Benjol Dec 23 '10 at 07:33
  • Ah, okay. So I take it that part is correct then. Difficult, this one. – Victor Zamanian Jan 08 '11 at 21:03
0

How do I go about telling git that I don't want to merge them, I just want to take 'theirs' each time?

That would be with a custom merge driver, that you can associate specifically with all binaries (*.dll, *.exe, *.so, ... whatever your particular binary extension is in your case)

See "git merge -s theirs needed — but I know it doesn't exist" for illustration.

What I haven't tested is: does the custom merge driver applies during a rebase --onto.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @VonC, one thing that's not clear to me in my scenario: where do I create the `.gitattributes` file? In commit C? – Benjol Feb 08 '11 at 07:48
  • @Benjol: good question. Commit C or F, depending on that "inversion" which occurs with the rebase... – VonC Feb 08 '11 at 08:17
  • @VonC, I tried (in a test repo) on C, seems to have worked! Further question: in my case, given that I want `theirs` of everything, couldn't I just do `echo * merge=keepTheirs > .gitattributes`, and then do a straight rebase onto? – Benjol Feb 08 '11 at 09:12
  • @Benjol: '*' is good for 'everything', even tough in this scenario I recently discovered the 'ours' merge strategy (which might not be useful in your specific case): http://stackoverflow.com/questions/4911794/git-command-for-making-one-branch-like-another/4912267#4912267 – VonC Feb 08 '11 at 09:17
  • @VonC, yeah, ours/theirs in the context of rebase just hurts my head :( – Benjol Feb 08 '11 at 09:23
  • @Benjol: I did make pretty drawings to illustrate that inversion though ;) http://stackoverflow.com/questions/3051461/git-rebase-keeping-track-of-local-and-remote/3052118#3052118 – VonC Feb 08 '11 at 09:26
  • @VonC, I know, but my head still hurts :) For some reason a simple `--onto` doesn't work, but no matter, now I'm going to try on the 'real' repo. – Benjol Feb 08 '11 at 09:38