Re: [RFC PATCH 00/12] Sparse checkout

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH 00/12] Sparse checkout

Jan Hudec
Hello,

sorry for replying to an old thread, but I am a bit puzzled here,

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 <[hidden email]> 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? That would however imply that it's /not/ an attribute of
the index, but the tree and therefore should be stored in a separate object.

The question whether it goes in the .git/config or .git/sparsecheckout is
than that of semantics -- if it's in .git/config, than user changes that by
editing the file or git config and no other way, while if it's in
.git/sparsecheckout, user changes it by running checkout with appropriate
arguments.

By the way, why is it *prefix*? Wouldn't a *path limit* be better?

--
                                                 Jan 'Bulb' Hudec <[hidden email]>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH 00/12] Sparse checkout

Johannes Schindelin
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH 00/12] Sparse checkout

Duy Nguyen
In reply to this post by Jan Hudec
On 8/4/08, Jan Hudec <[hidden email]> wrote:

> Hello,
>
>  sorry for replying to an old thread, but I am a bit puzzled here,
>
>
>  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 <[hidden email]> 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? That would however imply that it's /not/ an attribute of
>  the index, but the tree and therefore should be stored in a separate object.
>
>  The question whether it goes in the .git/config or .git/sparsecheckout is
>  than that of semantics -- if it's in .git/config, than user changes that by
>  editing the file or git config and no other way, while if it's in
>  .git/sparsecheckout, user changes it by running checkout with appropriate
>  arguments.

Please see the post Junio talked about narrow/sparse checkout [1].
With that approach (that is finer grain checkout than my approach), it
becomes clear that "prefix" is an attribute of index.

[1] http://article.gmane.org/gmane.comp.version-control.git/90016/match=narrow+checkout

>  By the way, why is it *prefix*? Wouldn't a *path limit* be better?

Well, yes "path limiter" seems a better term. But it's irrelevant now
because this approach won't fly. I'm going to wait to see if anyone
takes the task as part of hackontest. Otherwise I will redo my series,
using assume unchanged bit.

>  --
>                                                  Jan 'Bulb' Hudec <[hidden email]>
>


--
Duy
N�����r��y���b�X��ǧv�^�)޺{.n�+����ا���ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z��w���?����&�)ߢf�