git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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).