From: Junio C Hamano <gitster@pobox.com>
To: Koosha Khajehmoogahi <koosha@posteo.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/5] Add a new option 'merges' to revision.c
Date: Sun, 22 Mar 2015 18:25:07 -0700 [thread overview]
Message-ID: <xmqqegogbj4c.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <550F6175.9050606@posteo.de> (Koosha Khajehmoogahi's message of "Mon, 23 Mar 2015 01:42:29 +0100")
Koosha Khajehmoogahi <koosha@posteo.de> writes:
>>> } else if (!strcmp(arg, "--merges")) {
>>> + revs->max_parents = -1;
>>> revs->min_parents = 2;
>>
>> But is this change warranted? An existing user who is not at all
>> interested in the new --merges= option may be relying on the fact
>> that "--merges" does not affect the value of max_parents and she can
>> say "log --max-parents=2 --merges" to see only the two-way merges,
>> for example. This change just broke her, and I do not see why it is
>> a good thing.
>
> The point is that if you have your log.merges conf option set to 'hide'
> and you use git log --merges (two mutually conflicting options),
> git will silently exit without anything to show.
That is not an excuse to break "--merges" and "--no-merges" for
existing users who do not care about setting log.merges option to
anything.
The whole point of introducing a new "--merges=show" option was so
that people can sanely countermand log.merges configuration from the
command line without breaking --merges and --no-merges, wasn't it?
prev parent reply other threads:[~2015-03-23 1:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-22 18:28 [PATCH 1/5] Add a new option 'merges' to revision.c Koosha Khajehmoogahi
2015-03-22 18:28 ` [PATCH 2/5] Make git-log honor log.merges option Koosha Khajehmoogahi
2015-03-22 20:50 ` Eric Sunshine
2015-03-22 18:28 ` [PATCH 3/5] Update documentations for git-log to include the new --merges option and also its corresponding config option Koosha Khajehmoogahi
2015-03-22 21:17 ` Eric Sunshine
2015-03-22 18:28 ` [PATCH 4/5] Add tests for git-log --merges=show|hide|only Koosha Khajehmoogahi
2015-03-22 19:57 ` Torsten Bögershausen
2015-03-22 20:19 ` Eric Sunshine
2015-03-22 22:07 ` Koosha Khajehmoogahi
2015-03-22 22:40 ` Eric Sunshine
2015-03-22 22:41 ` Koosha Khajehmoogahi
2015-03-23 5:14 ` Torsten Bögershausen
2015-03-22 22:26 ` Eric Sunshine
2015-03-22 18:28 ` [PATCH 5/5] Update Bash completion script to include git log --merges option Koosha Khajehmoogahi
2015-03-22 21:24 ` Eric Sunshine
2015-03-23 1:23 ` SZEDER Gábor
2015-03-22 20:43 ` [PATCH 1/5] Add a new option 'merges' to revision.c Eric Sunshine
2015-03-22 23:31 ` Junio C Hamano
2015-03-23 0:42 ` Koosha Khajehmoogahi
2015-03-23 1:25 ` Junio C Hamano [this message]
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=xmqqegogbj4c.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.