threads / discuss / 30037

Listing commits that are _exclusively_ available on a given branch

Subject: Listing commits that are _exclusively_ available on a given branch

## tl;dr

5 messages between Mar 23, 2012 and Mar 23, 2012.

replies: 4people: 3as markdown or json

Johan Herland· Mar 23, 2012, 14:36 UTC · lore
Hi,

I'm trying to figure out how to list commits on a given branch that are not available on any other branch, i.e. the commits that are exclusive to my branch.

So far I only have this somewhat brute-force alternative:
  git rev-list refs/heads/mybranch --not $(git show-ref --heads | grep
-v refs/heads/mybranch)

Is it possible to phrase this query in a simpler manner? Preferably by not having to list all refs and then run grep on it...

(I've already tried playing around with "git show-branch" and its options, but to no avail.)

Have fun! :)
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Jeff King· Mar 23, 2012, 17:06 UTC · re: Johan Herland · lore

Re: Listing commits that are _exclusively_ available on a given branch

On Fri, Mar 23, 2012 at 03:36:33PM +0100, Johan Herland wrote:
Show 11 quoted lines
> I'm trying to figure out how to list commits on a given branch that
> are not available on any other branch, i.e. the commits that are
> exclusive to my branch.
> 
> So far I only have this somewhat brute-force alternative:
> 
>   git rev-list refs/heads/mybranch --not $(git show-ref --heads | grep
> -v refs/heads/mybranch)
> 
> Is it possible to phrase this query in a simpler manner? Preferably by
> not having to list all refs and then run grep on it...

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

You might consider using "git rev-list --stdin" to avoid running into limits on the command-line length.

-Peff
Junio C Hamano· Mar 23, 2012, 17:38 UTC · re: Jeff King · lore

Re: Listing commits that are _exclusively_ available on a given branch

Jeff King <peff@peff.net> writes:
Show 6 quoted lines
> 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?

Jeff King· Mar 23, 2012, 17:50 UTC · re: Junio C Hamano · lore

Re: Listing commits that are _exclusively_ available on a given branch

On Fri, Mar 23, 2012 at 10:38:32AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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). However, I think the double negation is necessary (i.e., you could not say "--include-ref"), because the two negations are talking about two different things (one is about limiting the list of items fed to the graph traversal, and the other is about limiting the graph traversal itself).

So yeah, I think that would work. But AFAIK, there has been no other activity on that topic.

-Peff
Junio C Hamano· Mar 23, 2012, 19:39 UTC · re: Jeff King · lore

Re: Listing commits that are _exclusively_ available on a given branch

Jeff King <peff@peff.net> writes:
Show 32 quoted lines
> 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.

← back to recent threads