On Tue, 26 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko <y...@onerussian.com> writes:
> > 1. As a workaround for absence of -m theirs I using mtheirs git alias: > > (I believe provided to me awhile back here on the list): > > mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m > > -u $1' - > > and it worked fine for my usecases > > 2. I think that if there is a reason for -s ours to exist, so there for -s > > theirs > > since it is just the directionality of merges which changes between the two > Just on this point. They are not exactly symmetric. > Imagine there are some undesirable changes you want to vanquish from > the world, but they have already built on useful changes on top of > the undesirable changes. A hypothetical history might look like > this: > B---C > / > X---X---A > / > ---o---o your mainline > where 'X' denotes those unwanted changes. > >...< > The symmetiric case where _you_ have wrong changes do not need "-s > theirs". These mistakes X are yours, so are the changes depend on > them: > B---C > / > X---X---A > / > ---o---o their mainline > and you can just rebase A, B and C on top of their mainline while > getting rid of Xs yourself before publishing. and that is where the gotcha comes -- what if "my" changes were already published? then I would like to avoid the rebase, and would -s theirs to choose "their" solution in favor of mine and be able to push so others could still "fast-forward" to the new state. So -- as to me it remains 'symmetric' ;) > There may be valid workflows that benefit from "-s theirs", and I > would not be surprised at all if we found more of them in the past 9 > years since we had the "why -s theirs does not exist" discussion in > 2008. But "because -s ours can be used in reverse to emulate" is > not a valid excuse to add "-s theirs". It can be used a rationale > against adding it (e.g. "-s theirs generally is discouraged because > it forsters a bad workflow, but in a very rare case where it might > be useful, you can always check out their branch and merge yours > using '-s ours' to emulate it, so we do not lose any functionality > even if we did not add it"), though. sure, git is flexible, so workarounds could always be found, but often many options are just a matter of convenience. And here -s theirs would be one of them besides my other use case where it is a somewhat "by design" workflow, and -s theirs is use to take their exact state I would improve upon (before committing the "merge") -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
