Re: restriction of pulls

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

Andy Parkins wrote:
> 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 ;-)

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