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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html