All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Koosha Khajehmoogahi <koosha@posteo.de>
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 10:53:43 -0700	[thread overview]
Message-ID: <xmqqpp88rfq0.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5506E751.8010506@posteo.de> (Koosha Khajehmoogahi's message of "Mon, 16 Mar 2015 15:23:13 +0100")

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;

  parent reply	other threads:[~2015-03-16 17:53 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 [this message]
2015-03-16 19:33   ` Koosha Khajehmoogahi
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=xmqqpp88rfq0.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=koosha@posteo.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.