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