git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Yaroslav Halchenko <yoh@onerussian.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re* BUG: merge -s theirs  is not in effect (does the same as -s ours)
Date: Mon, 25 Sep 2017 14:33:13 +0900	[thread overview]
Message-ID: <xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu> (Yaroslav Halchenko's message of "Sun, 24 Sep 2017 23:17:51 -0400")

Yaroslav Halchenko <yoh@onerussian.com> writes:

> d'oh, indeed there is no git-merge-theirs  neither in debian pkg or a freshly
> built git  and I found a rogue script in the PATH (which did nothing
> apparently, sorry!). BUT I was originally mislead by the --help/manpage:

Ahh, you're right.  The text does make readers expect "-s theirs" to
exist.

-- >8 --
Subject: merge-strategies: avoid implying that "-s theirs" exists

The description of `-Xours` merge option has a parenthetical note
that tells the readers that it is very different from `-s ours`,
which is correct, but the description of `-Xtheirs` that follows it
carelessly says "this is the opposite of `ours`", giving a false
impression that the readers also need to be warned that it is very
different from `-s theirs`, which in reality does not even exist.

Clarify it a bit to avoid misleading readers.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I hope this should help things a bit.

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

 Documentation/merge-strategies.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 2eb92b9327..a09d597463 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -39,7 +39,8 @@ even look at what the other tree contains at all.  It discards everything
 the other tree did, declaring 'our' history contains all that happened in it.
 
 theirs;;
-	This is the opposite of 'ours'.
+	This is the opposite of 'ours'; note that, unlike 'ours', there is
+	no 'theirs' merge stragegy to confuse this merge option with.
 
 patience;;
 	With this option, 'merge-recursive' spends a little extra time

  reply	other threads:[~2017-09-25  5:33 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     ` Junio C Hamano [this message]
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

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=xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=yoh@onerussian.com \
    /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).