Sam Vilain <sam@xxxxxxxxxx> writes:
> 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.
>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html