Sam Vilain <sam@vilain.net> writes:

quoted text
> It doesn't do that because the head doesn't match any revision that was
> given to us by `rev-list refs/remotes/foo/*`

Gaah.  That goes all the way down to the root commit.

+		print "fetching revs for ".@refs." remote refs\n";

Is this meant to be final message to the end-user, or debug?

+		my %r = map { ($_ => undef) }
+			$git->command("rev-list", @refs);

This traverses all the way down to the root commit, doesn't it?

That is probably good enough for a toy repository for testing,
but is impractical in real repositories, I am afraid.  See below
for the standard ways to check ancestry.

+		# don't delete the current branch
+		my ($checked_out) = $git->command(qw(symbolic-ref HEAD));

When the HEAD is detached, does the error message go directly to
the end user?

+		while ( my ($ref, $rev) = each %l ) {
+			next if $checked_out and $ref eq $checked_out;
+			if ( exists $r{$rev} ) {
+				print "$ref is obsolete\n";
+				$git->command(qw(update-ref -d), $ref, $rev);
+			}
+		}
 
The standard way to check if commit A is included in (i.e. is an
ancestor of) commit B, without traversing the ancestry chain of
B all the way down to the root commit, is to run:

	git merge-base --all A B

and see if A appears in its output (if so, then A is an ancestor
of B, otherwise it is not).  This is a pair-wise check, and for
your purpose the check would become N*M operation (Yuck).

The same check can be done in parallel with:

	git show-branch --independent A B C D...

whose output would include A if the commit is not included in
any of the other commits B C D...  This parallel traversal has a
limit --- you can only check 25 branches at a time.

quoted text
>> If the above is the usage scenario you are trying to help, then
>> wouldn't it be helpful if you could also help removing 'my-next'
>> in this slightly altered example?
>>
>> 	$ git clone
>>         ... time passes ...
>>         $ git checkout -b my-next origin/next
>>         ... build, install, have fun ...
>> 	$ git checkout master
>>         ... time passes ...
>>         $ git branch
>>         ... notice that you do not hack on your copy of 'next'
>>         ... which is 'my-next', and want to remove it
>> 	$ git remote prune -c
>
> Yes, the idea was to "sweep" all branches that were just local branches
> of a remote and never worked on. This is most useful right now for
> people switching from Cogito or old-style remotes, who have a lot of
> branches that are remote tracking branches. Using this, they can just
> set up a new remote, fetch and prune -c and be left in a tidy state.

You make it sound like this is just a one-shot conversion issue,
in which case I really doubt we would want that.  But it appears
to be a useful feature in general, provided if the assumed use
case is described clearly so that new users know when to use it.
In the form that was given to me, I think the documentation
leaves the user in a "Huh?" state.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html