From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Johan Herland <johan@herland.net>,
Git mailing list <git@vger.kernel.org>
Subject: Re: Listing commits that are _exclusively_ available on a given branch
Date: Fri, 23 Mar 2012 12:39:50 -0700 [thread overview]
Message-ID: <7v4ntft8c9.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120323175007.GA13410@sigill.intra.peff.net> (Jeff King's message of "Fri, 23 Mar 2012 13:50:07 -0400")
Jeff King <peff@peff.net> writes:
> On Fri, Mar 23, 2012 at 10:38:32AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > No, I think that is the only way to do it. The algorithm run by rev-list
>> > in that case should be optimal, so there is nothing to improve there.
>> > Syntactically, it's a little bit of a pain because there is no way to
>> > tell rev-list "--all, except for this one branch" short of using grep.
>> > We could add a new syntax for that, but I'm not sure what it would look
>> > like (or if it would be any easier on the eyes than what you have).
>>
>> We discussed --exclude-refs="refs/tags/expermental-*" that would affect
>> how --all, --heads, and friends are processed several weeks ago, didn't
>> we?
>
> Gmane seems to be down at the moment, but I think the thread you are
> talking about can be found here:
>
> http://mid.gmane.org/7v4nuvghfk.fsf@alter.siamese.dyndns.org
> http://mid.gmane.org/4F391F5C.1000400@alum.mit.edu
> http://mid.gmane.org/7vaa4meat5.fsf@alter.siamese.dyndns.org
>
> It talks about excluding from the positive side, like:
>
> git rev-list --all --exclude-ref=refs/heads/foo
>
> That can also be extended to the negative side, like:
>
> git rev-list refs/heads/foo --not --all --exclude-ref=refs/heads/foo
>
> though it is slightly confusing to read due to the double negation (you
> are "--not" "--exclude"-ing the ref).
The confusion comes only if you do not differentiate two independent
concepts, I think. --all and --exclude-ref are about what the starting
points of the traversal (i.e. what we would call add_rev_cmdline() and
add_pending_sha1() with), and --not is about the color in which these
pending objects will be painted.
The callpath leading to revisions.c::handle_one_ref() from setup_revisions()
must be revamped, so that "--all" does not immediately put them directly
in the pending array, but later "--exclude-ref" can subtract from the set,
before the starting points are determined and painted in their colors,
once we add --exclude-ref support.
prev parent reply other threads:[~2012-03-23 19:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 14:36 Listing commits that are _exclusively_ available on a given branch Johan Herland
2012-03-23 17:06 ` Jeff King
2012-03-23 17:38 ` Junio C Hamano
2012-03-23 17:50 ` Jeff King
2012-03-23 19:39 ` 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=7v4ntft8c9.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=peff@peff.net \
/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).