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

From: Yaroslav Halchenko <yoh@onerussian.com>
Date: Sep 25, 2017, 14:40 UTC
Message-ID: <20170925144021.vhbd3wb3uqejs5wq@hopa.kiewit.dartmouth.edu>
In-Reply-To: <xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com>

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 encourages the wrong workflow".

>    https://public-inbox.org/git/alpine.DEB.1.00.0807290123300.2725@eeepc-johanness/
>    https://public-inbox.org/git/7vtzen7bul.fsf@gitster.siamese.dyndns.org/
>    https://public-inbox.org/git/20080720192130.6117@nanako3.lavabit.com/

>    It is OK for people to come with new perspective and bring new
>    ideas to the table.  We learned from experience while using Git
>    for longer and are wiser than what we were back then, and might
>    be able to make a better decision ;-)

FWIW

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

3. My most frequently used use-case for -m theirs strategy is repositories such as

http://datasets.datalad.org/openfmri/ds000001/.git

where we construct "datalad dataset" by crawling the web resource(s), and workflow consists of 3 branches:

incoming             -- content from the web "as is"
incoming-processed   -- content from the web "processed" (fully automatically),
                        e.g. tarballs extracted etc
master               -- the "final" result, delivered to public

incoming-processed is formed by -s theirs --no-commit incoming, then all content needed to be extracted/processed (since last such merge point) is processed and commit is done. Such "merge" allows us to establish a point of previous "processing state" so we could react appropriately whenever anything in "incoming" branch changes (so that there is a new commit).

  And then incoming-processed is merged (regular recursive) into the
master branch, which might have further "manual" tune ups.

PS thanks for CCing replies

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