Re: restriction of pulls

From: Rogan Dawes <lists@dawes.za.net>
Date: Feb 12, 2007, 14:29 UTC
Message-ID: <45D079D3.2020500@dawes.za.net>
In-Reply-To: <Pine.LNX.4.63.0702121508360.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 14 quoted lines

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

Show 7 quoted lines

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

Show 5 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

> 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