Re: restriction of pulls

[Rogan Dawes <lists@dawes.za.net>]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 12 Feb 2007, Rogan Dawes wrote:
> 
>> Johannes Schindelin wrote:
>>> (my favourite:)
>>> - use git-split to create a new branch, which only contains doc/. Do work
>>> only on that branch, and merge into mainline from time to time.
>> Your third option sounds quite clever, apart from the problem of attributing a
>> commit and a commit message to someone, when the actual commit doesn't match
>> what they actually did :-(
> 
> This problem is not related to subprojects at all. If the commit message 
> does not match the patch, you are always fscked.

Well, I was thinking about the fact that the files originally checked in 
will not match the files "checked in" in the rewritten commit.

>> As well as wondering what happens when they check out a few more files. Do we
>> rewrite those commits as well? What happens if the user has made some commits
>> already? What happens if they have already sent those upstream? etc.
> 
> I think you misunderstood. My favourite option would make docs a 
> _separate_ project, with its own history. It just happens to be pulled 
> from time to time, just like git-gui, gitk and git-fast-import in git.git.

I see. However, that does not allow for the random single-file checkout 
scenario I sketched out. Which may or may not be common/desirable, but 
it is an extreme case of the partial checkout, without fixed delineation.

>> I think the best solution is ultimately to make git able to cope with 
>> certain missing objects.
> 
> Hmm. I am not convinced. On nice thing about git is its level of 
> integrity. Which means that no random objects are missing.

Good point. :-(

>> I started writing this in response to another message, but it will do fine
>> here, too:
>>
>> The description I give here will likely horrify people in terms of
>> communications inefficiency, but I'm sure that can be improved.
>>
>> [goes on... and describes the lazy clone!]
 >
> AFAICT this really is the lazy clone. And it was already determined that 
> it is all to easy to pull in all commit objects by accident. Which boils 
> down to a substantial chunk of the repository.
>

Not so much a lazy clone as a partial clone. It is only in the "clone", 
"fetch" or "checkout" code paths that new objects will be retrieved from 
the source repo. Things like "git log"/"git show" would not do so, and 
would be required to handle missing objects gracefully.

> But if you want to play with it: by all means, go ahead. It might just be 
> that you overcome the fundamental difficulties, and we get something nice 
> out of it.
> 
> Ciao,
> Dscho
> 

Maybe ;-) We'll see if I get any time for it.

Rogan