Re: [RFC PATCH 00/12] Sparse checkout

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

 



Hi,

On Sun, 3 Aug 2008, Jan Hudec wrote:

> 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@xxxxxx> 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

[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]

  Powered by Linux