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 16:31:23 -0700 [thread overview]
Message-ID: <xmqqoankbodw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1427048921-28677-1-git-send-email-koosha@posteo.de> (Koosha Khajehmoogahi's message of "Sun, 22 Mar 2015 19:28:37 +0100")
Koosha Khajehmoogahi <koosha@posteo.de> writes:
> @@ -1800,9 +1817,14 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
> revs->show_all = 1;
> } else if (!strcmp(arg, "--remove-empty")) {
> revs->remove_empty_trees = 1;
> + } else if (starts_with(arg, "--merges=")) {
> + if (parse_merges_opt(revs, arg + 9))
> + die("unknown option: %s", arg);
This one makes sense to me (so does what the parse_merges_opt()
does).
> } 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.
> } else if (!strcmp(arg, "--no-merges")) {
> + revs->min_parents = 0;
> revs->max_parents = 1;
Likewise.
next prev parent reply other threads:[~2015-03-22 23:31 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 [this message]
2015-03-23 0:42 ` Koosha Khajehmoogahi
2015-03-23 1:25 ` 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=xmqqoankbodw.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.