git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Yaroslav Halchenko <yoh@onerussian.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: -s theirs use-case(s) Was: BUG: merge -s theirs  is not in effect
Date: Wed, 27 Sep 2017 16:21:32 -0400	[thread overview]
Message-ID: <20170927202132.e4gqbozkczctci5z@hopa.kiewit.dartmouth.edu> (raw)
In-Reply-To: <20170927051915.tsxw2zycnjx4dyo4@hopa.kiewit.dartmouth.edu>


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

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

> 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        

      reply	other threads:[~2017-09-27 20:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25  0:02 BUG: merge -s theirs is not in effect (does the same as -s ours) Yaroslav Halchenko
2017-09-25  1:08 ` Junio C Hamano
2017-09-25  3:17   ` Yaroslav Halchenko
2017-09-25  5:33     ` Re* " Junio C Hamano
2017-09-25 14:30       ` -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26  1:56         ` Junio C Hamano
2017-09-26  2:16           ` Junio C Hamano
2017-09-26  2:39             ` Junio C Hamano
2017-09-26 13:37               ` Yaroslav Halchenko
2017-10-16  5:38                 ` [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge Junio C Hamano
2017-12-29  2:49                   ` Elijah Newren
2017-12-29  4:41                     ` Yaroslav Halchenko
2018-01-25  4:35                   ` external diff driver is not used for diff --stat? Yaroslav Halchenko
2017-09-25 14:40       ` -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26  3:45         ` Junio C Hamano
2017-09-26 13:32           ` Yaroslav Halchenko
2017-09-27  0:09             ` Junio C Hamano
2017-09-27  5:19               ` Yaroslav Halchenko
2017-09-27 20:21                 ` Yaroslav Halchenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170927202132.e4gqbozkczctci5z@hopa.kiewit.dartmouth.edu \
    --to=yoh@onerussian.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).