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
next prev parent 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).