On 03/16/2015 06:53 PM, Junio C Hamano wrote:
> Koosha Khajehmoogahi <koo...@posteo.de> writes:
>
>> This patch adds a 'showmerges' config. option for git-log.
>> This option determines whether the log should contain merge
>> commits or not. In essence, if this option is set to false,
>> git-log will be run as 'git-log --no-merges'.
>>
>> To force git-log to show merges even if 'log.showmerges' is
>> set, we use --include-merges command line option.
>
> Yuck.
>
> I agree that there is currently no way to revert the setting that is
> touched by --merges and --no-merges back to the default, but I think
> the right way to fix that is by streamlining these two options,
> instead of piling yet another kludge --include-merges on top.
>
> When we think about possible "canned" selection modes:
>
> (do we show merge commits?) * (do we show non-merge commits?)
>
> we have four combinations. Answering the above two questions with
> No/No would end up showing nothing, which is meaningless, so that
> leaves us three choices (of course, the user could choose to futz
> directly with min/max-parents to select only Octopus merges, but
> that is a more advanced/exotic usage).
>
> Wouldn't it make more sense to spell which selection mode the user
> wants with:
>
> git log --merges=<selection-mode>
>
> by naming the three meaningful selection modes with short and sweet
> names? Perhaps
>
> default? show? both? -- show both merge commits and non-merge commits
> only -- show only merge commits
> skip -- show only non-merge commits
>
> or something?
>
> Now, as I always say, I am not great at naming things, so do not
> take these names as the final suggestion, but I think you got the
> idea.
>
> Of course, then the traditional "--merges" option can be kept as a
> short-hand for "--merges=only", and "--no-merges" would become a
> short-hand for "--merges=skip".
>
> Once we have done that streamlining of the command line options, it
> will naturally follow that "log.merges = show | only | skip" would
> be a useful configuration option.
>
> I doubt we need an extra bit in rev_info to implement such a syntax
> sugar.
>
>> diff --git a/revision.h b/revision.h
>> index 0ea8b4e..f496472 100644
>> --- a/revision.h
>> +++ b/revision.h
>> @@ -145,6 +145,7 @@ struct rev_info {
>> unsigned int track_linear:1,
>> track_first_time:1,
>> linear:1;
>> + unsigned int force_show_merges:1;
>>
>> enum date_mode date_mode;
Thanks for your suggestions. The "extra bit" in rev_info is used when
we need to compare user's command-line input to his configuration. Since
command-line input is processed in revision.c but config. options are read
in builtin/log.c, we need a way to pass the value to builtin/log.c. How
would you do that without this extra bit?
--
Koosha
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
