git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Philip Oakley <philipoakley@iee.email>
Cc: Jeff King <peff@peff.net>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, me@ttaylorr.com,
	Derrick Stolee <dstolee@microsoft.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] revision: --include-diversions adds helpful merges
Date: Thu, 9 Apr 2020 13:20:57 -0400	[thread overview]
Message-ID: <63667043-dbca-0092-209d-865c2f60efc8@gmail.com> (raw)
In-Reply-To: <xmqqeeswodol.fsf@gitster.c.googlers.com>

On 4/9/2020 11:56 AM, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> 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.

After thinking about all the great responses here, and having a
chat with Dscho about this, then taking a break, I had an "Aha!"
moment. We should call this option:

	--show-pulls

The direction here is important. Let's look at a potential
"git log --graph --oneline" output to explore this idea:

	* (master) A
	|\
	| * (feature) B
	| |\
	| | *   (topic) C
	| | |\
	| | | |
	| | * | D
	| | | |
	| * | | E
	| | | |
	* | | | F
	| |_|/
	|/| |
	* | |   G
	|/ /
	* /     H
	|/
	*       I

I use (master), (feature), and (topic) to decorate branches
that are updated only by "git commit" or "git pull". The
file 'foo' was created by commit I.

In this graph, the single-parent commits G and D change 'foo'.
The commit G enters master using "git commit".

The commit G enters topic using "git pull" starting from D. The
developer on that branch resolves conflicts by taking the version
of 'foo' from D. Thus C is TREESAME to D but not G.

The commit B is created by running "git pull topic" from the
feature branch.

The commit A is created by running "git pull feature" from the
master branch.

Thus, A and B "pulled" the change into their branches. The
commit C "pulled" G into the branch, but did not keep the change
to 'foo'.

Thus 'git log --graph --oneline master -- foo' would output:


	* D
	* I

'git log --graph --oneline --show-pulls master -- foo' shows:

	* A
	* B
	* D
	* I

'git log --graph --oneline --full-history -- foo' shows:

	* (master) A
	|\
	| * (feature) B
	| |\
	| | *   (topic) C
	| | |\
	| | | |
	| | * | D
	| |_|/
	|/| |
	* | |   G
	|/ /
	| /
	|/
	*       I

'git log --graph --oneline --full-history --simplify-merges -- foo'
would show:

	*   C
	|\
	* | D
	| |
	| * G
	|/
	*   I

'git log --graph --oneline --full-history --simplify-merges --show-pulls -- foo'
would show:

	* A
	* B
	*   C
	|\
	* | D
	| |
	| * G
	|/
	*   I

In conclusion, I think "--show-pulls" provides the right context for these
extra merges to show in the history view. It also roots these merges in a
Git-native name (that also happens to evoke the "pull request" concept that
is _not_ native to Git).

What do you think?

Thanks,
-Stolee

  reply	other threads:[~2020-04-09 17:21 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
2020-04-09 17:20                       ` Derrick Stolee [this message]
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:
  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=63667043-dbca-0092-209d-865c2f60efc8@gmail.com \
    --to=stolee@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=philipoakley@iee.email \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: [PATCH] revision: --include-diversions adds helpful merges' \
    /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

Code repositories for project(s) associated with this 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).