Re: [RFC PATCH v2 3/4] unpack_trees(): add support for sparse checkout

Hi,

On Tue, 11 Aug 2009, Nguyen Thai Ngoc Duy wrote:

2009/8/10 Johannes Schindelin [off-list ref]:

quoted

On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:

quoted

This patch teaches unpack_trees() to checkout/remove entries on 
working directories appropriately when sparse checkout area is 
changed. Hook "sparse" is needed to help determine which entry will 
be checked out, which will not be.

When the hook is run, it is prepared with a pseudo index. The hook 
then can use "git update-index --[no-]assume-unchanged" to manipulate 
the index. It should not do anything else on the index. Assume 
unchanged information from the index will be used to shape working 
directory.

If I understand correctly, the purpose of the hook is to allow the 
user to mark something as unwanted preemptively, right?

If that is the sole reason for the hook, would it not be better to add 
support for a file .git/info/sparse which has the same syntax as 
.git/info/exclude, and which is used to determine if an 
added/modified/deleted file is supposed to be in the "sparse" area or 
not?

Something like

       *
       !/Documentation/

comes to mind.

That was what the original series was about (although I used git
config instead of .git/info/sparse). The hook has two advantages:

 - flexibility: you can set things differently based on branch, for 
   example, or filter files based on certain file content.

True, it is flexible.  The question is: is it not too flexible for its own 
good?

Having to introduce a hook means that every user either must trust another 
person and install the unmodified hook, or write the hook herself for 
every narrow work tree.

The branch use case you mentioned is maybe a good example what I mean by 
"too flexible":

- it is easy to get confused which parts are narrow or not if the hook can 
  change that depending on, say, the phase of the moon (okay, okay, 
  depending on the branch, but it is still confusing),

- the whole purpose of narrow checkout is to avoid having to check out 
  stuff that does not affect you.  Chances are that 99.99% of all "narrow" 
  users do not need to modify which slice of the files they want to see, 
  and those who do are probably better off with two work trees, methinks.

 - less code bloat (and less intrusive too), compare ~1000 lines of 
   change of the original series with this series.

Heh, see my other mail.  I'm sorry I forgot to mention that the similarity 
to .gitignore spares you a lot of code...

Ciao,
Dscho