Re: clone breaks replace
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 11, 2011, 17:56 UTC
- Message-ID
- <20110111175621.GC15133@burratino>
- In-Reply-To
- <20110111175031.GA2085@sigill.intra.peff.net>
Jeff King wrote:
Show 24 quoted lines
> I think you are stuck with something manual
> like:
>
> # grab "view" from upstream and name it; let's imagine it links 2010
> # history into 2009
> git fetch origin refs/replace/$sha1 refs/views/2009/$sha1
>
> # now we feel like using them
> git for-each-ref --shell --format='%(refname)' refs/views/2009 |
> while read ref; do
> git update-ref "refs/replace/${ref#refs/views/2009}" "$ref"
> done
>
> Which is a little overkill for the simple example you gave, but would
> also handle something as complex as a view like "pretend the foo/
> subtree never existed" or even "pretend the foo/ subtree existed all
> along".
>
> Not that I'm sure such things are actually sane to do, performance-wise.
> The replace system is fast, but it was designed for a handful of
> objects, not hundreds or thousands.
>
> Anyway. My point is that we don't have the porcelain to do something
> like managing views or enabling/disabling them in a sane manner.Maybe something like
git fetch origin refs/views/2009/*:refs/replace/*
except that that does not provide a nice way to remove to replace refs when done.
A potential usability enhancement might be to allow additional replacement hierarchies to be requested on a per command basis, like
GIT_REPLACE_REFS=refs/remotes/origin/views/2009 gitk --all
along the lines of GIT_NOTES_REF.