Re: clone breaks replace

[Jeff King <peff@peff.net>]

On Tue, Jan 11, 2011 at 09:40:17AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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