Re: restriction of pulls

Andy Parkins wrote:
> On Friday 2007 February 09 15:32, Rogan Dawes wrote:
> 
>> One obstacle to implementing partial checkouts is that one does not know
>> which objects have changed or been deleted. One way of addressing this
> 
> Why would you want to do a partial checkout.  I used subversion for a long 
> time before git, which does to partial checkouts and it's a nightmare.
> 
> Things like this
> 
>  cd dir1/
>  edit files
>  cd ../dir2
>  edit files
>  svn commit
>  * committed revision 100
> 
> KABLAM!  Disaster.  Revision 100 no longer compiles/runs.  The changes in dir1 
> and dir2 were complimentary changes (say like renaming a function and then 
> the places that call that function).

Please note that my suggestion does NOT imply allowing partial checkins 
(or if it does, it was not my intention)

What I am trying to support is Jon Smirl's description of how some 
Mozilla contributors work, specifically the documentation folks.

They do not have any need to look at the actual code, but simply limit 
themselves to the files in the doc/ directory.

Supporting a partial checkout of this doc/ directory would allow them to 
get a "check in"-able subdirectory, without having to download the rest 
of the source.

What I intended to convey was that when determining which files have 
changed, and presenting them to the user to decide whether to commit 
them or not, the filesystem-walker would first check the "negative 
index" to see if that directory/file had been explicitly excluded from 
the checkout. This implies that they did not (and do not intend to) 
modify that portion of the tree. Which implies that the committer can 
then construct a complete view of the entire tree (now including the 
changes that were made in the partial checkout) by resolving the 
modified files with the knowledge of the hashes of the unmodified 
files/trees.

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

Or at least if not check it in, construct a diff for mailing to the 
maintainer?

Or even, allowing the maintainer to pull/merge the changes from the 
contributor, even though the contributor doesn't necessarily have all 
the blobs required to make up the tree he is committing? They should all 
be available from the "alternate" if required.

Rogan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html