On Wed, Aug 29, 2007 at 07:08:21AM CEST, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
>
> > Theodore Tso <tytso@xxxxxxx> wrote:
> >> On Tue, Aug 28, 2007 at 12:10:59AM -0400, Shawn O. Pearce wrote:
> >> > Its what happens when you use `git clone --shared A B` and the
> > ...
> >> This has been discussed before, and it wouldn't be *that* hard to have
> >> "git clone --shared" create a backpointer from B to A, so that
> >> "git-prune" could also search the B's refs and not prune anything that
> >> is in A which is reachable from heads in A and B.
> >
> > Not if I already have a pointer from B to A's refs. repo.or.cz
> > also has this same pointer:
> >
> > git clone --shared A B
> > ln -s A/refs B/refs/forkee
>
> Two things to watch out for are (1) packed refs won't be
> protected with this trick, and (2) symrefs in refs/ hierarchy
> will point at wrong place if you did this. The latter hopefully
> won't be a problem because the trick being discussed is only to
> add reachability and not _using_ the borrowed refs for anything
> (iow, this makes B/refs/forkee/remote/origin/HEAD incorrectly
> point at refs/remotes/origin/master, but what it really should
> point at is B/refs/forkee/remote/origin/master).
BTW gitweb actually uses refs/forkee/ to add funny ref tags to commits,
which was completely unintended but is actually in the end quite handy
(though the tags should be modified to look less confusing).
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
-
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
