Re: clone breaks replace

From: Jeff King <peff@peff.net>
Date: Jan 11, 2011, 17:50 UTC
Message-ID: <20110111175031.GA2085@sigill.intra.peff.net>
In-Reply-To: <7vr5cj49vi.fsf@alter.siamese.dyndns.org>

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

Show 11 quoted lines

> 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