# on subtree checkout 13 messages from 2008-02-24 to 2008-02-26. Participants: Nguyen Thai Ngoc Duy, Robin Rosenberg, Jakub Narebski, Matthieu Moy, Johannes Schindelin, David Symonds. Thread: https://gitlist.dev/t/12289 ## Nguyen Thai Ngoc Duy, 2008-02-24 09:34 Subject: on subtree checkout Message-ID: URL: https://gitlist.dev/e/fcaeb9bf0802240134i46e276ajfe83071e0b18ce61%40mail.gmail.com ``` 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 ``` ## Robin Rosenberg, 2008-02-24 09:59 Subject: Re: on subtree checkout Message-ID: <200802241100.00107.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200802241100.00107.robin.rosenberg.lists%40dewire.com In-Reply-To: ``` 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 Narebski, 2008-02-24 10:03 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/m31w72d63a.fsf%40localhost.localdomain In-Reply-To: ``` "Nguyen Thai Ngoc Duy" 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 ``` ## Jakub Narebski, 2008-02-24 10:23 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/m3wsoubqmq.fsf%40localhost.localdomain In-Reply-To: <200802241100.00107.robin.rosenberg.lists@dewire.com> ``` Robin Rosenberg 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 ``` ## Robin Rosenberg, 2008-02-24 10:53 Subject: Re: on subtree checkout Message-ID: <200802241153.58009.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200802241153.58009.robin.rosenberg.lists%40dewire.com In-Reply-To: ``` söndagen den 24 februari 2008 skrev Jakub Narebski: > Robin Rosenberg 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 Narebski, 2008-02-24 11:53 Subject: Re: on subtree checkout Message-ID: <200802241253.11271.jnareb@gmail.com> URL: https://gitlist.dev/e/200802241253.11271.jnareb%40gmail.com In-Reply-To: <200802241153.58009.robin.rosenberg.lists@dewire.com> ``` Dnia niedziela 24. lutego 2008 11:53, Robin Rosenberg napisał: > söndagen den 24 februari 2008 skrev Jakub Narebski: >> Robin Rosenberg 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 ``` ## Nguyen Thai Ngoc Duy, 2008-02-24 15:12 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/fcaeb9bf0802240712u5bc7173du1fe67c3bcd89d1a4%40mail.gmail.com In-Reply-To: ``` On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski wrote: > > "Nguyen Thai Ngoc Duy" 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 ``` ## Jakub Narebski, 2008-02-24 15:45 Subject: Re: on subtree checkout Message-ID: <200802241645.49718.jnareb@gmail.com> URL: https://gitlist.dev/e/200802241645.49718.jnareb%40gmail.com In-Reply-To: ``` Nguyen Thai Ngoc Duy wrote: > On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski wrote: >> >> "Nguyen Thai Ngoc Duy" 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 Moy, 2008-02-24 15:59 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/vpqve4efiql.fsf%40bauges.imag.fr In-Reply-To: <200802241645.49718.jnareb@gmail.com> ``` Jakub Narebski writes: > Nguyen Thai Ngoc Duy wrote: >> On Sun, Feb 24, 2008 at 5:03 PM, Jakub Narebski wrote: >>> >>> "Nguyen Thai Ngoc Duy" 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 Rosenberg, 2008-02-24 17:22 Subject: Re: on subtree checkout Message-ID: <200802241822.42594.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200802241822.42594.robin.rosenberg.lists%40dewire.com In-Reply-To: ``` 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 Schindelin, 2008-02-26 01:59 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0802260156350.3322%40eeepc-johanness In-Reply-To: ``` 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 Symonds, 2008-02-26 02:30 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/ee77f5c20802251830p47c6de60je97a31cb34bc3105%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 25, 2008 at 5:59 PM, Johannes Schindelin 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. ``` ## Johannes Schindelin, 2008-02-26 11:23 Subject: Re: on subtree checkout Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0802261119590.17164%40racer.site In-Reply-To: ``` Hi, On Mon, 25 Feb 2008, David Symonds wrote: > On Mon, Feb 25, 2008 at 5:59 PM, Johannes Schindelin > 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 ```