Re: [RFC PATCH 00/12] Sparse checkout

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 3, 2008, 20:48 UTC
Message-ID: <alpine.DEB.1.00.0808032238170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
In-Reply-To: <20080803183749.GA3482@efreet.light.src>

Hi,

On Sun, 3 Aug 2008, Jan Hudec wrote:

Show 31 quoted lines

> On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >  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