All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Sam Vilain <sam@vilain.net>
Cc: git@vger.kernel.org
Subject: Re: [wishlist] git branch -d -r remotename
Date: Sun, 18 Mar 2007 23:18:34 -0700	[thread overview]
Message-ID: <7v8xdtkb7p.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: 45FDB322.10904@vilain.net

Sam Vilain <sam@vilain.net> 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.

  reply	other threads:[~2007-03-19  6:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18  9:36 [wishlist] git branch -d -r remotename Sam Vilain
2007-03-18 11:01 ` Sam Vilain
2007-03-18 11:01   ` Sam Vilain
2007-03-18 19:42     ` Junio C Hamano
2007-03-18 21:46       ` Sam Vilain
2007-03-19  6:18         ` Junio C Hamano [this message]
2007-03-19  6:40           ` Junio C Hamano
2007-03-19 23:37             ` (unknown) Sam Vilain

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=7v8xdtkb7p.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=sam@vilain.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.