list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Philip Oakley <>
Cc: Derrick Stolee <>, Jeff King <>,
	Derrick Stolee via GitGitGadget <>,,,
	Derrick Stolee <>,
	"brian m. carlson" <>
Subject: Re: [PATCH] revision: --include-diversions adds helpful merges
Date: Thu, 09 Apr 2020 08:56:42 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Philip Oakley's message of "Thu, 9 Apr 2020 15:28:15 +0100")

Philip Oakley <> writes:

>> Yes, but "redirect", "switch", "detour", or "divert" do not quite
>> mean "merging in a real change", at least to me.
>>> I'll just submit my v2 as-is, which includes a significant change to
>>> the documentation that should make things more clear.
>> Thanks.
> Can I suggest "--side-merges" as a possible descriptor for these
> non-mainline diversions?
> My thesaurus had suggested detour and sidetracked, which led to the
> side-merge view.

Ahh, sorry Derrick for being slow and thanks Philip for repeating
"diversion", as the word did not click for me at all when I saw the
patch and wrote my response.

But I think it started slowly to dawn on me.  

Does it come from the worldview where we want to follow the "trunk"
but because when we notice at a merge that we got everything that
matters to us from a side branch, we switch the track out of the
mainline and from then on follow that side branch?  Switching the
track and following the side branch happens silently with the
default "history simplification", but the new feature shows where
that side-tracking happens more prominently---is that where the
words "divert" etc. come from?

Then I can understand how these candidate words may have place in
describing the situation we want to use the feature; I am not yet
convinced any of the concrete option names floated on the thread (or
what I can come up with right now) would be clear to our target
audiences, but at least I am not as confused as I was before.


  reply	other threads:[~2020-04-09 15:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  1:22 Derrick Stolee via GitGitGadget
2020-04-08  1:30 ` Junio C Hamano
2020-04-08  1:39   ` Derrick Stolee
2020-04-08 15:28     ` Derrick Stolee
2020-04-08 19:46       ` Junio C Hamano
2020-04-08 20:05         ` Jeff King
2020-04-08 20:22           ` Derrick Stolee
2020-04-08 21:35             ` Junio C Hamano
2020-04-08 23:59               ` Derrick Stolee
2020-04-09  0:08                 ` Junio C Hamano
2020-04-09 11:52                   ` Derrick Stolee
2020-04-09 14:28                   ` Philip Oakley
2020-04-09 15:56                     ` Junio C Hamano [this message]
2020-04-09 17:20                       ` Derrick Stolee
2020-04-09 18:24                         ` Jeff King
2020-04-09 18:55                           ` Junio C Hamano
2020-04-09 19:21                             ` Jeff King
2020-04-08  2:13 ` brian m. carlson
2020-04-08 18:48 ` Jeff King
2020-04-09  0:01 ` [PATCH v2] " Derrick Stolee via GitGitGadget
2020-04-10 12:19   ` [PATCH v3] revision: --show-pulls " Derrick Stolee via GitGitGadget
2020-04-10 20:06     ` Junio C Hamano
2020-04-10 21:43       ` Derrick Stolee

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 inbox:

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