[MERGE] log --include-merges

[Ian Clatworthy]

John Arbash Meinel wrote:
> Ian Clatworthy wrote:
>> With patch this time. :-(
> 
>> Ian Clatworthy wrote:
>>> John Arbash Meinel wrote:
>>>
>>>> Vincent used the option "--include-merges" for this functionality as
>>>> part of "bzr missing" is there a reason to use a different option name?
>>> Not really. I'll change it. I'd also like to add a short option.
>>> I propose -n (and we extend the help message to say
>>> "Show (nested) merge revisions.").
>> Done. I've added -n as a shortcut option to missing as well.
> 
>> My only concern with the "include-merges" name is that users
>> migrating from git/hg might take it to mean something different, i.e.
>> whether to show/hide merge points. (Not that --merge-revisions
>> solved that.) I'm planning to give the help for log some love
>> once the various log patches I have in the review queue land.
> 
>> Ian C.
> 
> 
> 
> Would it be clearer as:
> 
> --mainline-only
> and
> --not-mainline-only

I believe --mainline-only could be potentially confusing because

  bzr log -r..x.y.z

will start from x.y.z and follow its "mergeline" before reaching and
displaying mainline revisions. If fact, if x.y.1 split off a.b.c instead
of off N, then additional merge revisions will be displayed between the
two sequences. At least that's the behavior I believe is correct and my
faster-log patch explicitly works that way.

So it comes down to flat vs nested.

> I don't like "-n" as the short option. Especially since it gets confused
> with "--no-include-merges". If we wanted 'n' then we should probably
> name it "--include-nested" or something along those lines. I do realize
> that 'm' is taken. I also realize that we don't have a way to do "-n" =>
> show, "-N" => no show.

Another possibility is --XXX=integer where 1 means flat and 0 means fully
nested. Options for XXX include --nested, --depth and --levels. I can
imagine some users liking to show just the one extra level down at times
instead of linear vs everything, particularly when using PQM.

Whatever we select, we should consider changing the missing command to
be consistent, yes?

> For now, I'd rather not have a short option until we determine if it is
> really necessary. Do you feel strongly about it?

No.

Ian C.