Re: [RFC] shallow clone

From: Simon Richter <simon.richter@hogyros.de>
Date: Jan 30, 2006, 13:25 UTC
Message-ID: <43DE13B4.8090403@hogyros.de>
In-Reply-To: <Pine.LNX.4.63.0601301305100.20228@wbgn013.biozentrum.uni-wuerzburg.de>

Hi,

Johannes Schindelin wrote:

[config as a registry]

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

Provided you have a parser that can handle it.

> 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.

Indeed. But we already have a method for associating data values with keys in a hierarchical namespace, and that one is pretty well tested. :-)

>>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.

What harm is done if I have an incomplete repository? It would probably make more sense to emit a warning on clone and explain things if the user tries to go to a version she doesn't have.

>>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).

Indeed, but you are keeping this information in two places, namely the grafts file and the config file. This is asking for trouble if they ever get out of sync.

>>>How about refs/tags/start_shallow?

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

> See above.

Well, I can however see the use case of a developer hosting an incomplete repo on a free web service and another developer wanting to merge her changes into her (complete) repo. You would have to specialcase this tag in the fetch operation to avoid copying it over.

What's probably worse: You can only have a single cutoff point that way. You probably want multiple in case you want to cut off at a place where development happened in multiple branches that got subsequently merged inside the window of objects you keep.

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

I would ask for the grafts parser to add "fake" grafts when it encounters the "shallow" file. Otherwise, it would be hard to distinguish between grafts the user made when doing interesting merges, and grafts that were created to build a shallow repo, because you would need some heuristics to figure out the latter from the former if you want to have a function in your porcelain to "pull more/all objects".

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

Yes. That is actually the reason I like git so much: I can repair it by hand if something breaks, and this can be done with simple commands. I can remove an object id from a file with "grep -v" or perl. I would need to fire up an editor or hack a longer script if I wanted to fix something inside a complex file that does multiple things.

    Simon