Re: [PATCH v2] rev-list-options.txt: start a list for `show-pulls`

["Martin Ågren" <martin.agren@gmail.com>]

On Tue, 26 May 2020 at 19:01, Derrick Stolee <stolee@gmail.com> wrote:
>
> 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