git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Koosha Khajehmoogahi <koosha@posteo.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH] [RFC] Add a new config. option for skipping merges in git-log
Date: Mon, 16 Mar 2015 20:33:47 +0100	[thread overview]
Message-ID: <5507301B.2060401@posteo.de> (raw)
In-Reply-To: <xmqqpp88rfq0.fsf@gitster.dls.corp.google.com>


On 03/16/2015 06:53 PM, Junio C Hamano wrote:
> Koosha Khajehmoogahi <koosha@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

  reply	other threads:[~2015-03-16 19:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 14:23 [PATCH] [RFC] Add a new config. option for skipping merges in git-log Koosha Khajehmoogahi
2015-03-16 15:27 ` Koosha Khajehmoogahi
2015-03-16 16:04   ` Koosha Khajehmoogahi
2015-03-16 17:53 ` Junio C Hamano
2015-03-16 19:33   ` Koosha Khajehmoogahi [this message]
2015-03-16 20:50     ` Junio C Hamano
2015-03-16 20:59       ` Koosha Khajehmoogahi
2015-03-16 21:58         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5507301B.2060401@posteo.de \
    --to=koosha@posteo.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).