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@xxxxxxxxxxxxxxxxxxxxxxxxxx/ > https://public-inbox.org/git/20080720192130.6117@xxxxxxxxxxxxxxxxxxx/ > 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
