Jeff King wrote:
> 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.
--
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