Re: [RFC] shallow clone

Hi,

On Mon, 30 Jan 2006, Simon Richter wrote:

Johannes Schindelin wrote:

quoted

quoted

. Set up `info/grafts` to lie to the local git that Linux kernel
 history began at v2.6.14 version.

quoted

Maybe also record this in .git/config, so that you can

I like that "config" thing less and less every day. It appears to become a
kind of registry, where having dedicated files for specific functionality
would provide the robustness of tools not having to touch things they do not
care about; but that's just personal opinion.

It is becoming sort of a registry: it contains metadata about the current 
repository, easily available to scripts and programs.

I beg to differ on your personal opinion on the grounds that the 
robustness comes from testing, not from diversity. I much prefer to have a 
well tested config mechanism to having dozens of differently formatted 
files with less-than-well tested parsers.

Thank you for the insights in your personal opinion anyway.

quoted

- disallow fetching from this repo, and

Why? It's perfectly acceptable to pull from an incomplete repo, as long as you
don't care about the old history.

Right. But should that be the default? I don't think so. Therefore: 
disable it, and if the user is absolutely sure to do dumb things, she'll 
have to enable it explicitely.

quoted

- easily extend the shallow copy to a larger shallow one, or a full one.

Hrm, I think there should also be a way to shrink a repo and "forget" old
history occasionally (obviously, use of that feature would be highly
discouraged).

Yes. And you need information about how shallow it used to be. My 
suggestion was to store that information at a place specific to that 
repository (see above).

quoted

quoted

. Run `git fetch git://.../linux-2.6 master`, with a local ref
 pointing at v2.6.14 commit, to pretend that we have everything
 up to v2.6.14 to `upload-pack` running on the other end.

quoted

How about refs/tags/start_shallow?

No, as that would imply that cloning from such a repo is disallowed.

See above.

IMO, it may be a lot more robust to just have a list of "cutoff" object ids in
.git/shallow instead of messing with grafts here, as adding or removing a line
from that file is an easier thing to do for porcelain (or by hand) than
rewriting the grafts file. Whether that list would be inclusive or exclusive
would need to be decided still.

The functionality of cutoff objects is included in grafts functionality, 
so why should we spend time on reimplementing a subset of features?

IMHO, adding and removing lines from scripts is fragile.

I beg your pardon, you want to edit this information *by hand*? Wow.

Ciao,
Dscho