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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Mon Sep 18 07:11:47 2006
This archive was generated by hypermail 2.1.8 : 2006-09-18 07:12:29 EST