Nguyen Thai Ngoc DuyI'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
Nguyen Thai Ngoc Duy
Robin RosenbergRe: on subtree checkout
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
Jakub NarebskiRe: on subtree checkout
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
Show 10 quoted lines
> 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
Robin RosenbergRe: on subtree checkout
söndagen den 24 februari 2008 skrev Jakub Narebski:
Show 16 quoted lines
> 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
Jakub NarebskiRe: on subtree checkout
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:
Show 15 quoted lines
>>>> 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
Jakub NarebskiRe: on subtree checkout
"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
Nguyen Thai Ngoc DuyRe: on subtree checkout
On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 12 quoted lines
>
> "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.
Show 5 quoted lines
> -- > Jakub Narebski > Poland > ShadeHawk on #git >
-- Duy
Jakub NarebskiRe: on subtree checkout
Nguyen Thai Ngoc Duy wrote:
Show 9 quoted lines
> 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
Matthieu MoyRe: on subtree checkout
Jakub Narebski <jnareb@gmail.com> writes:
Show 13 quoted lines
> 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
Robin RosenbergRe: on subtree checkout
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
Johannes SchindelinRe: on subtree checkout
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
David SymondsRe: on subtree checkout
On Mon, Feb 25, 2008 at 5:59 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 14 quoted lines
> 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.
Johannes SchindelinRe: on subtree checkout
Hi,
On Mon, 25 Feb 2008, David Symonds wrote:
Show 12 quoted lines
> 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