Re: [RFC PATCH v3 8/8] --sparse for porcelains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 16 Aug 2009, Johannes Schindelin wrote:
> On Sun, 16 Aug 2009, Jakub Narebski wrote:
>> On Sat, 15 Aug 2009, Junio C Hamano wrote:
>>> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>>> 
>>>>>> Hmmm... this looks like either argument for introducing --full 
>>>>>> option to git-checkout (ignore CE_VALID bit, checkout everything, 
>>>>>> and clean CE_VALID (?))...
>>>>>>
>>>>>>  ...or for going with _separate_ bit for partial checkout, like in 
>>>>>>  the very first version of this series, which otherwise functions 
>>>>>>  like CE_VALID, or is just used to mark that CE_VALID was set using 
>>>>>>  sparse.
>>> 
>>> How would a separate bit help?  Just like you need to clear CE_VALID 
>>> bit to revert the index into a normal (or "non sparse") state somehow, 
>>> you would need to have a way to clear that separate bit anyway.
>>> 
>>> A separate bit would help only if you want to handle assume-unchanged 
>>> and sparse checkout independently. But my impression was that the 
>>> recent lstat reduction effort addressed the issue assume-unchanged 
>>> were invented to work around in the first place.
>> 
>> Well, if we assume that we don't need (don't want) to handle 
>> assume-unchanged and sparse checkout independently, then of course the 
>> idea of having separate or additional bit for sparse doesn't make sense.
> 
> For the shallow/graft issue, we had a similar discussion.  Back then, I 
> was convinced that shallow commits and grafted commits were something 
> fundamentally different, and my recent patch to pack-objects shows that: 
> shallow commits do not have the real parents in the current repository, 
> and that makes them different from other grafted commits.
> 
> Now, if you want to say that assume-unchanged and sparse are two 
> fundamentally different things, I would be interested in some equally 
> convincing argument as for the shallow/graft issue.
> 
> There is a fundamental difference, I grant you that: the working directory 
> does not contain the "sparse'd away" files while the same is not true for 
> assume-unchanged files.
> 
> But does that matter?  The corresponding files are still in the index and 
> the repository.
> 
> IOW under what circumstances would you want to be able to discern between 
> assume-unchanged and "sparse'd away" files in the working directory?

>From what I understand it, assume-unchanged is performance optimization.
Sparse checkout is about files which are (assumed to) not be in working
directory, which means that they have to be assume-unchanged for git to
not try to access working area version of files which aren't there.

$GIT_DIR/info/sparse (or how it would be named; the name 'sparse' 
doesn't tell us whether patterns are about the files that are checked
out, or are about files which are not present in working directory)
is about specifying which files to checkout with "git checkout --sparse"
(or core.sparse / checkout.sparse = true).

> I could _imagine_ that you'd want a tool that allows you to change the 
> focus of the sparse checkout together with the working directory.  
> Example: you have a sparse checkout of Documentation/ and now you want to 
> have t/, too.  Just changing .git/info/sparse will not be enough.
> 
> The question is if the tool to change the "sparseness" [*1*] should not 
> change .git/info/sparse itself; if it does not, it would be good to be 
> able to discern between the "assume-unchanged" and "sparse'd away" files.
> 
> Although it might be enough to traverse the index and check the presence 
> of the assume-unchanged files in the working directory to determine which 
> files are sparse, and which ones are merely assume-unchanged.

There are quite a few possibilities: file can be marked "sparse" in
index (which also implies also marking it "assume-unchanged", if 
"assume-unchanged" doesn't work alone as "sparse" index bit) or not,
file can match 'no-checkout' pattern in $GIT_DIR/info/sparse or not,
file can be present in working directory or not:

 * match no-checkout
   - assume-unchanged
     + present in working directory
     + absent from working directory
   - no assume-unchanged
     + present
     + absent
 * doesn't match no-checkout
   - assume-unchanged
     + present
     + absent
   - no assume-unchanged
     + present
     + absent

> Footnote [*1*]: I think we need some nice and clear nomenclature here.  
> Any English wizards with a good taste of naming things?
 
English is not my native language, but what about:

 $GIT_DIR/info/
    no-checkout
    exclude-checkout
    workdir-exclude
    ignore-change
    assume-unchanged
    ghosts
  
-- 
Jakub Narebski
Poland
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]