Thread (53 messages) flat view 53 messages, 4 authors, 2016-06-15

Re: [PATCH 6/6] Add a new test for using a custom merge strategy

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:03

Hi,

On Mon, 28 Jul 2008, Miklos Vajna wrote:
Testing is done by creating a simple git-merge-theirs strategy which is 
the opposite of ours. Using this in real merges is not recommended but 
it's perfect for our testing needs.
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.

The -theirs which was asked for (and which I truly think is insane) wanted 
to do a merge, and in case of merge conflicts take the "upstream" version 
_only of the conflicting hunks_.

Just to make sure everyone grasps why this is bad:

- there is not only a real chance, but a high probability that a merge 
  conflict means that some related, unconflicting change relies on _one_ 
  version of the conflicting hunk which might very well be "ours", and

- since we have a _recursive_ merge, the notion of "upstream" is 
  completely bogus when working on any merge that has more than one merge 
  base.  This merge would succeed, but actively be wrong.

Just to make sure people do not have to ask for that version of 
"-theirs" again,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help