On Tue, 26 May 2020 at 19:01, Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 5/26/2020 11:16 AM, Junio C Hamano wrote: > > Martin Ågren <martin.agren@xxxxxxxxx> 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
