From: Derrick Stolee <firstname.lastname@example.org>
To: Junio C Hamano <email@example.com>
Cc: Jeff King <firstname.lastname@example.org>,
Derrick Stolee via GitGitGadget <email@example.com>,
Derrick Stolee <firstname.lastname@example.org>,
"brian m. carlson" <email@example.com>
Subject: Re: [PATCH] revision: --include-diversions adds helpful merges
Date: Wed, 8 Apr 2020 19:59:16 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 4/8/2020 5:35 PM, Junio C Hamano wrote:
> Derrick Stolee <email@example.com> writes:
>> Then I suppose we should focus on naming merge commits with this property:
>> A merge commit that is not TREESAME to its first parent (but is TREESAME
>> to a later parent).
>> The part in parentheses may be optional, because a merge commit that is
>> not TREESAME to any parent will be included by every history mode.
> A merge that is TREESAME to its first parent does not introduce
> anything new to the mainline (as far as the paths that match the
> pathspec are concerned). We are trying to find names to call merges
> that are not those no-op merges. Hmph...
There are three situations for a merge commit:
1. TREESAME to _all_ parents. These are not included.
2. not TREESAME to _all_ parents. These are already included.
3. TREESAME to some, but not TREESAME to others.
The third mode is the one that default mode will drop, but --full-history
will include. The new mode will include some of these (the ones that are
NOT TREESAME to their first parent).
>> In my latest attempt at documentation, I called these merges "diverters"
>> yet still used "--include-diversions". Here are a few other words that we
>> could use:
>> * diverters or diversions
>> * redirects
>> * switches (think railroad switch). Synonym: exchange
>> * detours
> ...none of the above tells me that they are not no-op (in other
> words, they do something meaningful), so I must be coming from
> a direction different from you are. What redirects from what other
> thing, for example?
The merges do something meaningful: they "merge in" a "real" change.
I'll just submit my v2 as-is, which includes a significant change to
the documentation that should make things more clear.
next prev parent reply other threads:[~2020-04-08 23:59 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 [this message]
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
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
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: 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 \
* 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).