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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 11, 2009, 07:02 UTC
Message-ID: <alpine.DEB.1.00.0908110850470.4638@intel-tinevez-2-302>
In-Reply-To: <fcaeb9bf0908101847w7b3b22d9w84514a29ceae719e@mail.gmail.com>

Hi,

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

Show 36 quoted lines

> 2009/8/10 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Mon, 10 Aug 2009, Nguyễn Thái Ngọc Duy wrote:
> >
> >> 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