From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Making pathspec limited log play nicer with --first-parent
Date: Thu, 19 Jan 2012 12:43:10 -0800 [thread overview]
Message-ID: <7vwr8niftt.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CA+55aFxucaeX7it_Kj7WV3ZbwCukN+wvbuxqJzh3V5Rxz4ib1g@mail.gmail.com> (Linus Torvalds's message of "Thu, 19 Jan 2012 12:15:53 -0800")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Jan 19, 2012 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Comments?
>
> Looks conceptually right, but I do have to admit to hating that new variable.
>
> I don't see a better way to do it, though. Sure, you could do it with just
>
> if (revs->first_parent_only && pp != &commit->parents)
> break;
>
> and avoid the new variable that way, but that replaces the annoying
> variable with a pretty subtle thing.
>
> Or we could re-write that while() loop and move the 'parent' variable
> into it. Like the appended untested thing.
>
> But maybe your patch is better, and my dislike for that parent counter
> is just irrational.
I didn't like that parent counter that _only_ increments when we are
running under first-parent-only mode at the conceptual level. At the
implementation level, of course it is the right thing to do because
outside first-parent-only mode nobody cares about the parent counter,
so it is a valid but subtle optimization.
But I personally find your loop
do {
...
} while (!revs->first_parent_only);
is even more disgusting. It is misleading to have something that is not
supposed to change inside the loop as the terminating condition as if we
are saying "loop until somebody flips that bit" which is clearly not the
case.
So obviously I am saying that I do not think either patch is pretty
without offering a better alternative implementation, which is my usual
badness. As this is not an ultra urgent fix, I'll wait and see if somebody
else comes up with a more readable version.
Thanks for eyeballing the logic side of it, anyway. That was what I was
worried about the change the most.
next prev parent reply other threads:[~2012-01-19 20:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 19:58 [RFC] Making pathspec limited log play nicer with --first-parent Junio C Hamano
2012-01-19 20:15 ` Linus Torvalds
2012-01-19 20:43 ` Junio C Hamano [this message]
2012-01-19 20:48 ` Linus Torvalds
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=7vwr8niftt.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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