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....@gitster.siamese.dyndns.org/
>    https://public-inbox.org/git/20080720192130.6...@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        

Reply via email to