git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / 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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).