Jakub Narebski wrote:
A Large Angry SCM wrote:
Jakub Narebski wrote:
A Large Angry SCM wrote:
There is no fundamental reason Git can not support partial
checkouts/working directories. In fact, there is no fundamental reason
Git can not support operations on partial (sparse?) repositories in both
space (working content/state, etc.) and time (history); it's just a
matter of record keeping[*1*]. That isn't how the Linux kernel
developers want to use their VCS but it _is_ how others want to use
theirs.
There is perhaps not much trouble with partial checkouts, but there is
problem with partial _commits_, at least for snapshot based SCM
(as opposed to patchset based SCM).
By "partial commit" I take it you mean a commit with only partial
information about the new (content) state? If so, the missing
information about the new state can be assumed to have not changed from
the previous recorded state (commit).
That of course assumes that 1) the whole state is recorded somewhere
(perhaps in the repository); so the partial checkout saves space only if
repository compress really well, 2) there are no merges outside checked out
part.
1) The TREE objects leading to the objects that are
added/deleted/changed objects are required. TREEs not leading to the
added/deleted/changed objects are not required, only their IDs. That is
sufficient to commit the changes in a partial checkout.
2) Obviously, only the part checked out can be worked on. If you want to
merge changes to some other part, you will need that part, and possibly
a mergebase.
-
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