Re: [PATCH v2] rev-list-options.txt: start a list for `show-pulls`
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- May 26, 2020, 19:20 UTC
- Message-ID
- <CAN0heSp-D8qfKzDfBYxLA-76v=E_VgKWtfitCFb8DdWiHqMDmw@mail.gmail.com>
- In-Reply-To
- <474bbf51-bd40-837a-77de-1688f6488ae3@gmail.com>
On Tue, 26 May 2020 at 19:01, Derrick Stolee <stolee@gmail.com> wrote:
Show 29 quoted lines
> > On 5/26/2020 11:16 AM, Junio C Hamano wrote: > > Martin Ågren <martin.agren@gmail.com> writes: > > > > This is not a new issue introduced by this patch, but ... > > > >> +--show-pulls:: > >> + In addition to the commits shown in the default history, show > >> + each merge commit that is not TREESAME to its first parent but > >> + is TREESAME to a later parent. > >> + > >> +When a merge commit is included by `--show-pulls`, the merge is > >> treated as if it "pulled" the change from another branch. When using > >> `--show-pulls` on this example (and no other options) the resulting > >> graph is: > > > > ... "is treated AS IF" somewhat made me go "huh?"; with or without > > the option, the merge did pull the change from another branch, > > didn't it? The only effect the option has is to make that fact > > stand out in the output. > > I guess the 'as if it "pulled" the change from another branch' sentence > is literally talking about the "git pull" command, as opposed to the > "git merge" command, or creating the merge upon completion of a pull request > on a Git service (which is almost always using libgit2 to generate a merge > commit). > > Perhaps there is no semantic difference between "pulling" and "merging" > and then this could be reworded to be less awkward.
Agreed on the awkwardness as it stands (before or after this proposed patch). I don't have any concrete thoughts to offer though.
Martin