Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

From: Yaroslav Halchenko <yoh@onerussian.com>
Date: Sep 27, 2017, 20:21 UTC
Message-ID: <20170927202132.e4gqbozkczctci5z@hopa.kiewit.dartmouth.edu>
In-Reply-To: <20170927051915.tsxw2zycnjx4dyo4@hopa.kiewit.dartmouth.edu>

On Wed, 27 Sep 2017, Yaroslav Halchenko wrote:

Show 5 quoted lines

> > 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, nullifying what the other line of
> > history did.

> > So I still do not think the above scenario justifies "-s theirs".

Show 5 quoted lines

> ok, when you describe it like this (in my case I rarely cared about the
> side of the merge), then indeed I might better do the entire dance with
> git reset --hard theirstate; git merge -s ours HEAD@{1}
> and live happily with the left side being the one always correct and
> hide "my" mistakes ;)  will keep it in mind

ha -- was about to use it, which reminded me about this use case!

NB pardon me for not so wonderful ascii-diagrams as yours but hopefully still helps

              x-o-o-o-x-o-o    debian
             /        /
             x-------x-----    releases -- should just linearly sweep through releases I care about
            /       /
           R1      R2          various release branches/tags
           A       B           which have differing commits
          /       /
      ---o---o----o----o        masteg

For packaging some packages for Debian, with my git-rotten-soul, I am trying to keep my debian packaging (in a branch "debian") on top of upstream releases. But the problem comes whenever upstream releases from "release branches", which are never merged into master and might have different and conflicting changes.

So, it becomes impossible to maintain a linearly progressing "debian" branch without adding a middle-man between upstream releases (in release branches), and debian branch (should progress linearly forward) -- "releases" branch. See e.g. http://github.com/neurodebian/pandas and its releases branch.

so I use -s theirs for "linearizing" the branched up development history

-- 
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