Re: [RFC PATCH 00/12] Sparse checkout

Hi,

On Sun, 3 Aug 2008, Jan Hudec wrote:

On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:

quoted

On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:

quoted

On 7/23/08, Johannes Schindelin [off-list ref] wrote:

quoted

 On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:

 > So in short, sparse prefix will be stored in config, 
 > core.sparsecheckout.

Do you really think the prefix should be stored anywhere else than 
the index?

With core.sparseCheckout you have to introduce a _sh*tload_ of 
config loaders.

And with core.sparseCheckout you are at the whim of the user, 
since .git/config is _supposed_ to be user-editable.

From a logical point of view, I'd say that the sparse prefix has 
nothing to do with the "configuration" of the local repository.

Well, whatever place. I chose .git/config because I did not want to 
introduce a new config place. But then how about 
.git/sparsecheckout?

No, I did mean the index.  This is an attribute of the index: either 
it is sparsely checked out or not.  You can even have multiple indices 
(switching between them by setting GIT_INDEX_FILE) which have 
different prefixes.

Um, but does the prefix we want to use depend on what files are 
physically present in the tree?

The thing is: in a checkout, the flow of data is

	HEAD -> index -> worktree

To check in, the flow is exactly opposite.

There are also legal workflows where you do not work on the worktree at 
all.

And there are legal workflows where you work with multiple 
indices/worktrees.

Now, it appears pretty obvious to me that the logical thing is to tell the 
(current) index what is supposed to be checked out and what not.

After all, a merge is done inside the index.  And if the merge touches 
parts outside of the sparse checkout, it is natural to have the index know 
about it.

Because the merge _has_ to complain then.

In any case, isn't it clearly the more elegant solution to just put the 
information into the index when you touch it _anyway_?

I am really puzzled why people think it is a good idea to separate the 
file metadata from the information what files were checked out to begin 
with, as if they were totally independent.

Because they are not.

Ciao,
Dscho