Re: restriction of pulls

From: Rogan Dawes <lists@dawes.za.net>
Date: Feb 9, 2007, 17:32 UTC
Message-ID: <45CCB041.1000500@dawes.za.net>
In-Reply-To: <200702091645.33384.andyparkins@gmail.com>

Andy Parkins wrote:

Show 7 quoted lines

> On Friday 2007 February 09 16:36, Rogan Dawes wrote:
> 
>> Please note that my suggestion does NOT imply allowing partial checkins
>> (or if it does, it was not my intention)
> 
> My apologies then; I did misunderstand.
>

That'll teach me to be more clear ;-)

Show 10 quoted lines

> 
>>> In every way that matters you can do a partial checkout - I can pull any
>>> version of any file out of the repository.  However, it should certainly
>>> not be the case that git records that fact.
>> Why not? If you only want to modify that file, does it not make sense
>> that you can just check out that file, modify it, and check it back in?
> 
> Sorry - what I meant was that it shouldn't record that you checked out 
> revision 74 of that file and retain a link from the current version to that 
> old version.

Well, the new commit would have the previous commit as its direct parent, even though it may not have all the blobs to support it.

Which implies that all the git merge semantics should still work, assuming that the person actually doing the merge has all the necessary objects to resolve any conflicts. (Which does not necessarily imply that he has ALL of the objects in the tree, just those that are implicated in any conflicts).

So, for example, the doc team may have a documentation maintainer who has the entire doc/ directory, who resolves any submissions from the doc team, and feeds that up into the master tree. And all of this could be done by means of pulls by the upstream maintainers.

Rogan