Re: Notes on supporting Git operations in/on partial Working Directories

[A Large Angry SCM <gitzilla@gmail.com>]

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.