on subtree checkout

on subtree checkout

[Nguyen Thai Ngoc Duy]

I'm going to implement subtree checkout. The plan is to save "index
prefix" in GIT_DIR/prefix and update git commands to use index prefix
when accessing the index. If I'm heading a wrong way, stop me now.

Thanks
-- 
Duy

Re: on subtree checkout

[Robin Rosenberg]

söndagen den 24 februari 2008 skrev Nguyen Thai Ngoc Duy:
> I'm going to implement subtree checkout. The plan is to save "index
> prefix" in GIT_DIR/prefix and update git commands to use index prefix
> when accessing the index. If I'm heading a wrong way, stop me now.

Make it multivalue as having more than one directory checked out is quite reasonable in for example Eclipse, where there are hundreds of plugins all
listed at the top level, but you only need a checkout for those that you actually want to change. KDE would be another example where you want to mention multiple roots.

-- robin

Re: on subtree checkout

[Jakub Narebski]

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

> I'm going to implement subtree checkout. The plan is to save "index
> prefix" in GIT_DIR/prefix and update git commands to use index prefix
> when accessing the index. If I'm heading a wrong way, stop me now.

If I remember correctly previous trials to implement "partial
checkout" ("subtree checkout") feature, or at least discussions about
it, used index extension.

As far as I can see the problem lies in merging...
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: on subtree checkout

[Jakub Narebski]

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

> söndagen den 24 februari 2008 skrev Nguyen Thai Ngoc Duy:
> > I'm going to implement subtree checkout. The plan is to save "index
> > prefix" in GIT_DIR/prefix and update git commands to use index prefix
> > when accessing the index. If I'm heading a wrong way, stop me now.
> 
> Make it multivalue as having more than one directory checked out is
> quite reasonable in for example Eclipse, where there are hundreds of
> plugins all listed at the top level, but you only need a checkout
> for those that you actually want to change. KDE would be another
> example where you want to mention multiple roots.

IMHO both in case of Eclipse plugins, and KDE modules/apps/whatever
it would be much better to use submodules support than partial
checkouts.

IMHO the best example of partial checkout workflow would be
documentation writers or translators. You cannot put docs in separate
submodule, as you want to have whole-tree change+documantation update
commits.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: on subtree checkout

[Robin Rosenberg]

söndagen den 24 februari 2008 skrev Jakub Narebski:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> 
> > söndagen den 24 februari 2008 skrev Nguyen Thai Ngoc Duy:
> > > I'm going to implement subtree checkout. The plan is to save "index
> > > prefix" in GIT_DIR/prefix and update git commands to use index prefix
> > > when accessing the index. If I'm heading a wrong way, stop me now.
> > 
> > Make it multivalue as having more than one directory checked out is
> > quite reasonable in for example Eclipse, where there are hundreds of
> > plugins all listed at the top level, but you only need a checkout
> > for those that you actually want to change. KDE would be another
> > example where you want to mention multiple roots.
> 
> IMHO both in case of Eclipse plugins, and KDE modules/apps/whatever
> it would be much better to use submodules support than partial
> checkouts.

400 submodules... noway.

-- robin

Re: on subtree checkout

[Jakub Narebski]

Dnia niedziela 24. lutego 2008 11:53, Robin Rosenberg napisał:
> söndagen den 24 februari 2008 skrev Jakub Narebski:
>> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>>> söndagen den 24 februari 2008 skrev Nguyen Thai Ngoc Duy:

>>>> I'm going to implement subtree checkout. The plan is to save "index
>>>> prefix" in GIT_DIR/prefix and update git commands to use index prefix
>>>> when accessing the index. If I'm heading a wrong way, stop me now.
>>> 
>>> Make it multivalue as having more than one directory checked out is
>>> quite reasonable in for example Eclipse, where there are hundreds of
>>> plugins all listed at the top level, but you only need a checkout
>>> for those that you actually want to change. KDE would be another
>>> example where you want to mention multiple roots.
>> 
>> IMHO both in case of Eclipse plugins, and KDE modules/apps/whatever
>> it would be much better to use submodules support than partial
>> checkouts.
> 
> 400 submodules... noway.

Way.

IHMO rule of thumb is: use submodules support if projects are
independent, or at least largely independent.
-- 
Jakub Narebski
Poland

Re: on subtree checkout

[Nguyen Thai Ngoc Duy]

On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
>  > I'm going to implement subtree checkout. The plan is to save "index
>  > prefix" in GIT_DIR/prefix and update git commands to use index prefix
>  > when accessing the index. If I'm heading a wrong way, stop me now.
>
>  If I remember correctly previous trials to implement "partial
>  checkout" ("subtree checkout") feature, or at least discussions about
>  it, used index extension.
>
>  As far as I can see the problem lies in merging...

Can you elaborate? I'm really noob at merging.

>  --
>  Jakub Narebski
>  Poland
>  ShadeHawk on #git
>



-- 
Duy

Re: on subtree checkout

[Jakub Narebski]

Nguyen Thai Ngoc Duy wrote:
> On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>>
>>> I'm going to implement subtree checkout. [...]
>>
>>  As far as I can see the problem lies in merging...
> 
> Can you elaborate? I'm really noob at merging.

What to do if when merging, or rebasing, there is conflict _outside_
checked out subtree?

-- 
Jakub Narebski
Poland

Re: on subtree checkout

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> Nguyen Thai Ngoc Duy wrote:
>> On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>>>
>>>> I'm going to implement subtree checkout. [...]
>>>
>>>  As far as I can see the problem lies in merging...
>> 
>> Can you elaborate? I'm really noob at merging.
>
> What to do if when merging, or rebasing, there is conflict _outside_
> checked out subtree?

I suppose you have to forbid merges where anything non-trivial happens
outside the tree (i.e. allow it only if the set of renamed or changed
files is disjoint outside the tree, or only if only one of the
branches to merge have changes outside the tree).

That's probably not such a big limitation in practice for the user,
since by definition the user won't modify the files outside its tree,
so he can at least still merge with the branch he branched from.

I can see another problem: partial checkout is really interesting only
if you can do a partial clone ("partial" here in the sense "subtree").
Otherwise, your .git/ still eats your disk space and "clone" still
needs your bandwidth for something you won't use.

-- 
Matthieu

Re: on subtree checkout

[Robin Rosenberg]

söndagen den 24 februari 2008 skrev Matthieu Moy:
> I suppose you have to forbid merges where anything non-trivial happens
> outside the tree (i.e. allow it only if the set of renamed or changed
> files is disjoint outside the tree, or only if only one of the
> branches to merge have changes outside the tree).
One still has to allow it, maybe forcing a bigger checkout in those
cases.

> That's probably not such a big limitation in practice for the user,
> since by definition the user won't modify the files outside its tree,
> so he can at least still merge with the branch he branched from.
Partial checkout is for convenience and speed of worktree operations as 
I see it. Other people could have other reasons for it. Branch switching takes a lot of time with big repos, same thing with git status, add -u etc. Restricting the worktree scan for uninteresting parts speeds things up.

> I can see another problem: partial checkout is really interesting only
> if you can do a partial clone ("partial" here in the sense "subtree").
> Otherwise, your .git/ still eats your disk space and "clone" still
> needs your bandwidth for something you won't use.

Better and more of "global" operations on repos with submodules might make them more bearable, and maybe even convenient, for example doing a git diff
over a set of submodules detecting renames between submodules.

-- robin

Re: on subtree checkout

[Johannes Schindelin]

Hi,

On Sun, 24 Feb 2008, Nguyen Thai Ngoc Duy wrote:

> I'm going to implement subtree checkout. The plan is to save "index
> prefix" in GIT_DIR/prefix and update git commands to use index prefix
> when accessing the index. If I'm heading a wrong way, stop me now.

As I wrote a long time ago already, I think the correct approach would be 
to reuse the code for the core.ignoreStat feature.

But I agree with others that you should think about sane implementations 
of rebase/merge with partial checkouts.

Ciao,
Dscho

Re: on subtree checkout

[David Symonds]

On Mon, Feb 25, 2008 at 5:59 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
>  On Sun, 24 Feb 2008, Nguyen Thai Ngoc Duy wrote:
>
>  > I'm going to implement subtree checkout. The plan is to save "index
>  > prefix" in GIT_DIR/prefix and update git commands to use index prefix
>  > when accessing the index. If I'm heading a wrong way, stop me now.
>
>  As I wrote a long time ago already, I think the correct approach would be
>  to reuse the code for the core.ignoreStat feature.
>
>  But I agree with others that you should think about sane implementations
>  of rebase/merge with partial checkouts.

I, too, was shortly going to attempt a partial checkout/clone
implementation. The intended context of my implementation was similar
to the KDE scenario in that you might only care about /pkgA and /pkgB,
so changes to /pkgC are usually irrelevant and independent to your
work-flow, so I was planning to assume a simplistic "theirs" merge
strategy for /pkgC, etc.


Dave.

Re: on subtree checkout

[Johannes Schindelin]

Hi,

On Mon, 25 Feb 2008, David Symonds wrote:

> On Mon, Feb 25, 2008 at 5:59 PM, Johannes Schindelin 
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > But I agree with others that you should think about sane 
> > implementations of rebase/merge with partial checkouts.
> 
> I, too, was shortly going to attempt a partial checkout/clone 
> implementation. The intended context of my implementation was similar to 
> the KDE scenario in that you might only care about /pkgA and /pkgB, so 
> changes to /pkgC are usually irrelevant and independent to your 
> work-flow, so I was planning to assume a simplistic "theirs" merge 
> strategy for /pkgC, etc.

That might work for the people who have partial checkouts.  But I see a 
lot of problems looming there: just imagine a documenter rebased on top of 
'master', and _then_ on top of a branch by another documenter, which is 
newer with respect to documentation, but older with respect to the code.

It is _really_ easy to break code if you have no intention to test the 
result of a merge, _especially_ so when it is a "theirs" strategy.

Ciao,
Dscho