theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
- From
- Sverre Rabbelier <alturin@gmail.com>
- Date
- Jul 28, 2008, 14:54 UTC
- Message-ID
- <bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com>
On Mon, Jul 28, 2008 at 15:12, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 6 quoted lines
> Note that what was asked for, and what Junio implemented before deciding > that it would do more harm than good in git.git, is not the same as what > you provide. > > Your -theirs is a strict opposite of -ours, i.e. the tree after the > merge will be identical to the "merged" branch's tip's.
I've been wanting to mail about this for a few days now, but didn't really know how to bring it up, this seems a good opportunity.
It has happened a few times on #git already that someone asked for the merge strategies described above (e.g., _not_ the insane ones) for what I deemed to be valid use cases. (The main reason was that they wanted to merge with a conflicting branch, discarding the current master, but still allowing people to 'git pull'.)
I was wondering what to tell those people? Will there ever be such a version of 'merge theirs' (that is the strict opposite of 'ours')? Or should they do:
$git checkout otherbranch $git merge -s ours master $git checkout master $git merge otherbranch
Thus resulting in a 'wrong way around' merge as part of master? It would say "Merge branch 'master' into otherbranch", while what happened was "Merge branch 'otherbranch' into master".
So, in short: what does the list think about adding "git-merge-theirs", that does (although possibly less 'hackish'):
cat > git-merge-theirs << EOF #!/bin/sh eval git read-tree --reset -u \\\$\$# EOF
-- Cheers, Sverre Rabbelier