On Mon, Jul 28, 2008 at 15:12, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
