On Tue, Jan 11, 2011 at 09:40:17AM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > Sure, I think that is a sane way for the user to think about it, but do
> > we actually support multiple views? I thought replacement objects were
> > all or nothing.
>
> It is not implausible for a long running large project to restart their
> history from a physical root commit every year, stiching the year-long
> segments together at their ends with replacements, to make a default clone
> to get a year's worth of the most recent history while allowing people to
> get more by asking, no?
Oh, absolutely I think it is reasonable. I just meant that we do not
have a convenient way of saying "fetch these replace objects, but only
use this particular subset". 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.
-Peff
--
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