Re: [RFC] shallow clone

From: Simon Richter <simon.richter@hogyros.de>
Date: Jan 31, 2006, 13:05 UTC
Message-ID: <43DF608C.1060201@hogyros.de>
In-Reply-To: <Pine.LNX.4.63.0601311127490.25248@wbgn013.biozentrum.uni-wuerzburg.de>

Hi,

Johannes Schindelin wrote:

>>If the downstream person wants to have a shallow history of post
>>X.org X server core to further hack on it, I do not think of a
>>reason why we would want to refuse her from cloning a repository
>>of a fellow developer who has already done such a shallow copy.

> Okay. But in their case, they'll probably do what was done with Linux: 
> start afresh. If you want to have the old history, you can import it and 
> merge it via a graft.

Well, in the Linux case the problem was not knowing what the SHA1 sum of the entire Linux history was. In the shallow repo case we know it, so there is no point in throwing away that information.

>>If such a clone is done without telling the downstream that the
>>result is a shallow one, it is "dumb".  I would agree it should
>>not be done.

> That was my point. As long as you don't make sure the client handles the 
> shallow upstream gracefully, it is dangerous. At the moment, there are too 
> many code parts relying on the completeness of the repository (local and 
> remote).

Well, the important thing would be that commands that can work (a merge only needs to find the most recent common ancestor, etc) do work, and commands that cannot ("log") emit sensible diagnostics.

Show 5 quoted lines

> Just imagine this: Alice starts a project, Bob makes a shallow copy from 
> it when Alice just reverted an experimental feature. Then, Alice decides 
> the experimental feature was not bad at all and reverts the revert. Bob 
> pulls from Alice: Alice's upload-pack assumes Bob already has the original 
> files (now re-reverted), and Bob ends up with a broken repository.

I know far too little about the internal workings for that, but I'd assume that in this case Bob's copy starts at the commit that was never in question (and he never saw the reverted commit), and Alice's contains a commit on top of that. That one should work. But the other way 'round is problematic, when Bob starts with a commit that has been reverted in Alice's repository. The solution is for Bob to ask Alice's repo for the common ancestor of his shallow base and Alice's HEAD. Alice's repo can, however, fail to deliver these if there has been a purge since, in that case, stuff needs to be merged by hand (but you already have a problem if someone clones your repo before you revert changes, so no regression here).

> If you now rely on the grafts file to determine what was a cutoff, you may 
> well end up with bogus cutoffs.

Exactly that was my concern earlier; my database design gut feeling tells me that information duplication is not good either, hence my suggestion to split off these grafts into a separate file in order to mark them as cutoff points.

    Simon