On Wed, 27 Sep 2017, Yaroslav Halchenko wrote:
> > And at that point, use of "-s ours" is no longer a workaround for
> > lack of "-s theirs". It is a proper part of the desired semantics,
> > i.e. from the point of view of the surviving canonical history line,
> > you want to preserve what it did
On Wed, 27 Sep 2017, Junio C Hamano wrote:
> > 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-for
Yaroslav Halchenko writes:
> 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.
On Tue, 26 Sep 2017, Junio C Hamano wrote:
> Yaroslav Halchenko 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
Yaroslav Halchenko 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
On Mon, 25 Sep 2017, Junio C Hamano wrote:
>It is a different matter to resurrect the age old discussion that
>happend in the summer of 2008 if '-s theirs' should or should not
>exist. In short, the previous discussion can be summarised to
>"we don't want '-s theirs' as it encoura
6 matches
Mail list logo