{"thread":{"id":"14619","subject":"[RFC PATCH 00/12] Sparse checkout","startedAt":"2008-07-23T14:55:18Z","lastAt":"2008-08-04T12:29:24Z","messageCount":27,"participants":["Nguyễn Thái Ngọc Duy","Nguyen Thai Ngoc Duy","Johannes Schindelin","James Pickens","Jakub Narebski","Avery Pennarun","Jan Hudec"],"isPatch":true,"patchVersion":1,"patchTotal":12},"messages":[{"id":"84506","messageId":"20080723145518.GA29035@laptop","threadId":"14619","inReplyTo":null,"subject":"[RFC PATCH 00/12] Sparse checkout","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-23T14:55:18Z","receivedAt":"2008-07-23T14:55:18Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"I have not looked at non-builtin commands yet, but I think it's not\na big deal. We have several rounds before this series is good enough ;)\nSo in short, sparse prefix will be stored in config, core.sparsecheckout.\nyou have three new commands to enter/update/leave sparse checkout:\n\ngit clone --path=prefix # clone with sparse checkout\ngit checkout --path=prefix # limit/update checkout paths\ngit checkout --full # stop sparse checkout\n\nOther operations should be normal. User attempts to do anything outside\nsparse checkout will get flagged. Git itself should not touch anything\noutside sparse checkout.\n\nOne more thing. As files outside sparse checkout will not be checking\nout, .gitignore and .gitattributes from parent directories (outside\nsparse checkout) will be gone too. This may lead to surprise.\n\nComments are welcome.\n\nNguyễn Thái Ngọc Duy (12):\n git-grep: read config\n git-grep: support --no-external-grep\n Introduce sparse prefix\n Protect index with sparse prefix\n tests for sparse checkout, index protection\n Avoid accessing working directory outside sparse prefix\n tests for sparse checkout, worktree protection\n git-clone: support --path to do sparse clone\n tests for sparse clone\n git-checkout: support --full and --path to manipulate sparse checkout\n tests for checkout [--full|--path]\n git-status: print sparse checkout status\n\n builtin-add.c | 4 +-\n builtin-apply.c | 5 +\n builtin-checkout-index.c | 2 +\n builtin-checkout.c | 46 ++++++-\n builtin-clean.c | 3 +\n builtin-clone.c | 13 ++\n builtin-commit.c | 13 ++-\n builtin-grep.c | 36 +++--\n builtin-ls-files.c | 6 +-\n builtin-ls-tree.c | 2 +-\n builtin-merge-recursive.c | 6 +-\n builtin-mv.c | 2 +-\n builtin-read-tree.c | 5 +\n builtin-rev-parse.c | 4 +\n builtin-rm.c | 7 +-\n builtin-update-index.c | 37 ++++-\n cache.h | 19 +++\n config.c | 7 +\n diff-lib.c | 5 +-\n diff.c | 3 +-\n entry.c | 3 +\n environment.c | 221 ++++++++++++++++++++++++++\n read-cache.c | 112 +++++++++++++-\n setup.c | 90 +++++++++++-\n sha1_file.c | 3 +\n t/t2010-checkout-sparse.sh | 71 +++++++++\n t/t2300-sparse-index.sh | 156 +++++++++++++++++++\n t/t2300/diff-index-sub.expected | 3 +\n t/t2300/log.expected | 64 ++++++++\n t/t2301-sparse-index-merge-recursive.sh | 226 +++++++++++++++++++++++++++\n t/t2302-sparse-worktree.sh | 113 ++++++++++++++\n t/t2302/add-u.expected | 1 +\n t/t2302/add.expected | 2 +\n t/t2302/commit.expected | 14 ++\n t/t2302/diff-1.expected | 7 +\n t/t2302/diff-cc.expected | 9 +\n t/t2302/grep-work.expected | 2 +\n t/t2302/grep.expected | 2 +\n t/t2302/ls-files.expected | 2 +\n t/t2303-sparse-worktree-apply.sh | 62 ++++++++\n t/t2303/apply-initial.patch | 14 ++\n t/t2303/apply-inside.patch | 7 +\n t/t2303/apply-leading-dirs.patch | 3 +\n t/t2303/apply-outside.patch | 7 +\n t/t2303/apply-remove.patch | 7 +\n t/t2303/apply-rename.expected | 13 ++\n t/t2303/apply-rename.patch | 4 +\n t/t2304-sparse-worktree-merge-recursive.sh | 233 ++++++++++++++++++++++++++++\n t/t5703-clone-sparse.sh | 40 +++++\n unpack-trees.c | 152 +++++++++++++++++--\n unpack-trees.h | 4 +-\n wt-status.c | 12 +-\n 52 files changed, 1831 insertions(+), 53 deletions(-)\n create mode 100755 t/t2010-checkout-sparse.sh\n create mode 100755 t/t2300-sparse-index.sh\n create mode 100644 t/t2300/diff-index-sub.expected\n create mode 100644 t/t2300/log.expected\n create mode 100755 t/t2301-sparse-index-merge-recursive.sh\n create mode 100755 t/t2302-sparse-worktree.sh\n create mode 100644 t/t2302/add-u.expected\n create mode 100644 t/t2302/add.expected\n create mode 100644 t/t2302/commit.expected\n create mode 100644 t/t2302/diff-1.expected\n create mode 100644 t/t2302/diff-cc.expected\n create mode 100644 t/t2302/grep-work.expected\n create mode 100644 t/t2302/grep.expected\n create mode 100644 t/t2302/ls-files.expected\n create mode 100755 t/t2303-sparse-worktree-apply.sh\n create mode 100644 t/t2303/apply-initial.patch\n create mode 100644 t/t2303/apply-inside.patch\n create mode 100644 t/t2303/apply-leading-dirs.patch\n create mode 100644 t/t2303/apply-outside.patch\n create mode 100644 t/t2303/apply-remove.patch\n create mode 100644 t/t2303/apply-rename.expected\n create mode 100644 t/t2303/apply-rename.patch\n create mode 100755 t/t2304-sparse-worktree-merge-recursive.sh\n create mode 100755 t/t5703-clone-sparse.sh\n"},{"id":"84522","messageId":"fcaeb9bf0807230838u4f82601bu6dcec0ed038e9611@mail.gmail.com","threadId":"14619","inReplyTo":"20080723145518.GA29035@laptop","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-23T15:38:02Z","receivedAt":"2008-07-23T15:38:02Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Sorry list. Forgot --thread in format-patch :(\n-- \nDuy\n"},{"id":"84534","messageId":"alpine.DEB.1.00.0807231713280.8986@racer","threadId":"14619","inReplyTo":"20080723145518.GA29035@laptop","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T16:15:44Z","receivedAt":"2008-07-23T16:15:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n\n> So in short, sparse prefix will be stored in config, core.sparsecheckout.\n\nDo you really think the prefix should be stored anywhere else than the \nindex?\n\nWith core.sparseCheckout you have to introduce a _sh*tload_ of config \nloaders.\n\nAnd with core.sparseCheckout you are at the whim of the user, since \n.git/config is _supposed_ to be user-editable.\n\n>From a logical point of view, I'd say that the sparse prefix has nothing \nto do with the \"configuration\" of the local repository.\n\nCiao,\nDscho\n"},{"id":"84537","messageId":"fcaeb9bf0807230921m114f5ae0ybfec4917432d6dc7@mail.gmail.com","threadId":"14619","inReplyTo":"alpine.DEB.1.00.0807231713280.8986@racer","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-23T16:21:02Z","receivedAt":"2008-07-23T16:21:02Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/23/08, Johannes Schindelin wrote:\n> Hi,\n>\n>\n> On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n>\n> > So in short, sparse prefix will be stored in config, core.sparsecheckout.\n>\n>\n> Do you really think the prefix should be stored anywhere else than the\n> index?\n>\n> With core.sparseCheckout you have to introduce a _sh*tload_ of config\n> loaders.\n>\n> And with core.sparseCheckout you are at the whim of the user, since\n> .git/config is _supposed_ to be user-editable.\n>\n> From a logical point of view, I'd say that the sparse prefix has nothing\n> to do with the \"configuration\" of the local repository.\n\nWell, whatever place. I chose .git/config because I did not want to\nintroduce a new config place. But then how about .git/sparsecheckout?\n\n>\n> Ciao,\n> Dscho\n>\n\n\n-- \nDuy\n"},{"id":"84546","messageId":"alpine.DEB.1.00.0807231753240.8986@racer","threadId":"14619","inReplyTo":"fcaeb9bf0807230921m114f5ae0ybfec4917432d6dc7@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T16:55:14Z","receivedAt":"2008-07-23T16:55:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/23/08, Johannes Schindelin wrote:\n>\n> > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n> >\n> > > So in short, sparse prefix will be stored in config, \n> > > core.sparsecheckout.\n> >\n> > Do you really think the prefix should be stored anywhere else than the \n> > index?\n> >\n> > With core.sparseCheckout you have to introduce a _sh*tload_ of config \n> > loaders.\n> >\n> > And with core.sparseCheckout you are at the whim of the user, since \n> > .git/config is _supposed_ to be user-editable.\n> >\n> > From a logical point of view, I'd say that the sparse prefix has \n> > nothing to do with the \"configuration\" of the local repository.\n> \n> Well, whatever place. I chose .git/config because I did not want to \n> introduce a new config place. But then how about .git/sparsecheckout?\n\nNo, I did mean the index. This is an attribute of the index: either it is \nsparsely checked out or not. You can even have multiple indices \n(switching between them by setting GIT_INDEX_FILE) which have different \nprefixes.\n\nCiao,\nDscho \"who seems to recall that the first series was much less intrusive\"\n"},{"id":"84688","messageId":"loom.20080724T065737-580@post.gmane.org","threadId":"14619","inReplyTo":"20080723145518.GA29035@laptop","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2008-07-24T08:24:30Z","receivedAt":"2008-07-24T08:24:30Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"Nguyễn Thái Ngọc Duy gmail.com> writes:\n\n> I have not looked at non-builtin commands yet, but I think it's not\n> a big deal. We have several rounds before this series is good enough ;)\n> So in short, sparse prefix will be stored in config, core.sparsecheckout.\n> you have three new commands to enter/update/leave sparse checkout:\n> \n> git clone --path=prefix # clone with sparse checkout\n> git checkout --path=prefix # limit/update checkout paths\n> git checkout --full # stop sparse checkout\n>\n\nFirst things first, thanks a lot for working on this feature. I have an\nenormous project in CVS (144GB repo, containing 65000 directories and\n463000 files) that I've been wanting to convert to git for a while now,\nand the lack of sparse checkouts was the only thing about git that was\nstanding in the way. The project is so big that checking out the whole\ntree all the time is unworkable, and I think my coworkers would hang me\nif I tried to make them use submodules. We already use sparse checkouts\nin CVS to make it manageable, so sparse checkout support in git would\nvastly simplify the transition.\n\nI played around with the patch briefly, and I have a couple of comments\non the interface.\n\nFirst, I would want a capability to checkout a directory non-recursively.\nI.e., checkout directory A/B, without also checking out directory A/B/C.\nPerhaps a modifier could be added to a path element to make it\nnon-recursive.\n\nSecond, I would want a capability to checkout and release directories\nincrementally, similar to how we do it in cvs. For example, I might do\nthe following in cvs:\n\n$ cvs co -l A # Checkout dir A non-recursively\n$ cd A\n$ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively\n$ cd B1\n$ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively\n(Oops, didn't need C2)\n$ cvs release -d C2\n\nAt this point I would have the following directory tree, assuming the C1\ndirectory in the repo contained a D1 directory:\n\nA/\nA/B1/\nA/B1/C1/\nA/B1/C1/D1/\nA/B2/\n\nA similar capability in git would be much appreciated.\n\nFinally, I noticed what I think is a bug: if you do a partial checkout of\na non-existing directory, you just get an empty tree. I would expect to\nget an error message in that case.\n\nI hope this is helpful, and thanks again for working on this.\n\nJames\n"},{"id":"84685","messageId":"fcaeb9bf0807240127p5226822atcd4a0711f1bc9c5c@mail.gmail.com","threadId":"14619","inReplyTo":"alpine.DEB.1.00.0807231753240.8986@racer","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T08:27:03Z","receivedAt":"2008-07-24T08:27:03Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/23/08, Johannes Schindelin wrote:\n> Hi,\n>\n>\n> On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 7/23/08, Johannes Schindelin wrote:\n> >\n>\n> > > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> > >\n> > > > So in short, sparse prefix will be stored in config,\n> > > > core.sparsecheckout.\n> > >\n> > > Do you really think the prefix should be stored anywhere else than the\n> > > index?\n> > >\n> > > With core.sparseCheckout you have to introduce a _sh*tload_ of config\n> > > loaders.\n> > >\n> > > And with core.sparseCheckout you are at the whim of the user, since\n> > > .git/config is _supposed_ to be user-editable.\n> > >\n> > > From a logical point of view, I'd say that the sparse prefix has\n> > > nothing to do with the \"configuration\" of the local repository.\n> >\n> > Well, whatever place. I chose .git/config because I did not want to\n> > introduce a new config place. But then how about .git/sparsecheckout?\n>\n>\n> No, I did mean the index. This is an attribute of the index: either it is\n> sparsely checked out or not. You can even have multiple indices\n> (switching between them by setting GIT_INDEX_FILE) which have different\n> prefixes.\n\nI don't think so. It's a mask for workdir, right? If you save it it\nindex, you can switch index and the prefix as well, but workdir only\nhas several subtrees that do not fit any other prefix than the\noriginal prefix.\n\n> Ciao,\n> Dscho \"who seems to recall that the first series was much less intrusive\"\n\nThe first series only took care of index, so yes it's simpler.\n-- \nDuy\n"},{"id":"84692","messageId":"fcaeb9bf0807240200x10a6a267h4c37e4566da967ba@mail.gmail.com","threadId":"14619","inReplyTo":"loom.20080724T065737-580@post.gmane.org","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T09:00:16Z","receivedAt":"2008-07-24T09:00:16Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/24/08, James Pickens wrote:\n> Nguyen Thai Ngoc Duy gmail.com> writes:\n>\n> > I have not looked at non-builtin commands yet, but I think it's not\n> > a big deal. We have several rounds before this series is good enough ;)\n> > So in short, sparse prefix will be stored in config, core.sparsecheckout.\n> > you have three new commands to enter/update/leave sparse checkout:\n> >\n> > git clone --path=prefix # clone with sparse checkout\n> > git checkout --path=prefix # limit/update checkout paths\n> > git checkout --full # stop sparse checkout\n> >\n>\n>\n> First things first, thanks a lot for working on this feature. I have an\n> enormous project in CVS (144GB repo, containing 65000 directories and\n> 463000 files) that I've been wanting to convert to git for a while now,\n> and the lack of sparse checkouts was the only thing about git that was\n> standing in the way. The project is so big that checking out the whole\n> tree all the time is unworkable, and I think my coworkers would hang me\n> if I tried to make them use submodules. We already use sparse checkouts\n> in CVS to make it manageable, so sparse checkout support in git would\n> vastly simplify the transition.\n>\n> I played around with the patch briefly, and I have a couple of comments\n> on the interface.\n>\n> First, I would want a capability to checkout a directory non-recursively.\n> I.e., checkout directory A/B, without also checking out directory A/B/C.\n> Perhaps a modifier could be added to a path element to make it\n> non-recursive.\n\nThis one is difficult (and may probably produce more intrusive patch).\nLet's see what I can do.\n\n> Second, I would want a capability to checkout and release directories\n> incrementally, similar to how we do it in cvs. For example, I might do\n> the following in cvs:\n>\n> $ cvs co -l A # Checkout dir A non-recursively\n> $ cd A\n> $ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively\n> $ cd B1\n> $ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively\n> (Oops, didn't need C2)\n> $ cvs release -d C2\n> At this point I would have the following directory tree, assuming the C1\n> directory in the repo contained a D1 directory:\n>\n> A/\n> A/B1/\n> A/B1/C1/\n> A/B1/C1/D1/\n> A/B2/\n>\n> A similar capability in git would be much appreciated.\n\nYou can do that with \"git checkout --path\" (non-recursive checkout aside):\n\n$ git checkout --path=A # checkout full A\n$ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only\n$ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too\n\n>\n> Finally, I noticed what I think is a bug: if you do a partial checkout of\n> a non-existing directory, you just get an empty tree. I would expect to\n> get an error message in that case.\n\nThanks.\n\n> I hope this is helpful, and thanks again for working on this.\n>\n> James\n>\n>\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nDuy\n"},{"id":"84693","messageId":"m3tzefvd3q.fsf@localhost.localdomain","threadId":"14619","inReplyTo":"20080723145518.GA29035@laptop","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-24T09:35:45Z","receivedAt":"2008-07-24T09:35:45Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> I have not looked at non-builtin commands yet, but I think it's not\n> a big deal. We have several rounds before this series is good enough ;)\n> So in short, sparse prefix will be stored in config, core.sparsecheckout.\n> you have three new commands to enter/update/leave sparse checkout:\n> \n> git clone --path=prefix # clone with sparse checkout\n> git checkout --path=prefix # limit/update checkout paths\n> git checkout --full # stop sparse checkout\n> \n> Other operations should be normal. User attempts to do anything outside\n> sparse checkout will get flagged. Git itself should not touch anything\n> outside sparse checkout.\n> \n> One more thing. As files outside sparse checkout will not be checking\n> out, .gitignore and .gitattributes from parent directories (outside\n> sparse checkout) will be gone too. This may lead to surprise.\n> \n> Comments are welcome.\n\nA note: my comments here reflects what I have remember from reading\ncomments in this thread; I have not examined the code, though.\n\n\nFirst, I think that 'sparse checkout' is a better idea than former\n'subtree (partial) checkout'; and I guess it could be easier to code.\n\n\nSecond, I think you can simply special case .git* files (.gitignore,\n.gitattributes, .gitmodules), and always check them out for all\nintermediate directories (unless configured otherwise, of course).\nSo for example if you have the following directory structure:\n\n A/.gitignore\n A/a\n A/B1/.gitignore\n A/B1/b\n A/B2/.gitignore\n A/B2/c\n\nand you are checking out only subdirectory 'B1' (and all files in it;\nif subdirectories are checked out recursively it depends on\nconfiguration), and if for example there is .gitignore in every\ndirectory, then checked out tree would look like this:\n\n A/.gitignore\n A/B1/.gitignore\n A/B1/b\n\nThe ability to do this is one of advantages of 'sparse' checkout over\n'subtree' checkout.\n\n\nThird, about the place where to store information about which paths\nare checked out, and which are not. There are three possible places\nto store this information:\n\n 1. repository configuration, e.g. `core.sparsecheckout' variable\n (multivalued?), like for `core.worktree'\n\n 2. some text file in $GIT_DIR, e.g. '.git/sparse', like for shallow\n clone (\"git clone --depth \") it is grafts-like\n $GIT_DIR/shallow (see Documentation/technical/shallow.txt).\n\n 3. in the index itseld ($GIT_DIR/index), as proposed by Johannes\n Schindelin.\n\nWhile I do think that some information about sparseness should be in\nthe index, for git to be able to commit from the index for example,\nI don't think it is a good place as the only/main place to store\ninformation about which paths are checked out; I think that because\nIMVHO git commands should survive hosing (removing) index file.\n\nJust my 2 eurocents.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"84701","messageId":"fcaeb9bf0807240358l6584c063u85179196bd6db30a@mail.gmail.com","threadId":"14619","inReplyTo":"m3tzefvd3q.fsf@localhost.localdomain","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T10:58:57Z","receivedAt":"2008-07-24T10:58:57Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/24/08, Jakub Narebski wrote:\n> Second, I think you can simply special case .git* files (.gitignore,\n> .gitattributes, .gitmodules), and always check them out for all\n> intermediate directories (unless configured otherwise, of course).\n> So for example if you have the following directory structure:\n>\n> A/.gitignore\n> A/a\n> A/B1/.gitignore\n> A/B1/b\n> A/B2/.gitignore\n> A/B2/c\n>\n> and you are checking out only subdirectory 'B1' (and all files in it;\n> if subdirectories are checked out recursively it depends on\n> configuration), and if for example there is .gitignore in every\n> directory, then checked out tree would look like this:\n>\n> A/.gitignore\n> A/B1/.gitignore\n> A/B1/b\n>\n> The ability to do this is one of advantages of 'sparse' checkout over\n> 'subtree' checkout.\n\nOr teach git to use index version of those files. Or collect all those\nfiles, combine them and put the result to .git/info/exclude (and\nsimilar places). Anyway well organized repos won't have this problem.\n\nChecking some files out as read-only (like this case) may be\ninteresting. Though I do not how much complicated it can be.\n-- \nDuy\n"},{"id":"84709","messageId":"alpine.DEB.1.00.0807241340490.8986@racer","threadId":"14619","inReplyTo":"fcaeb9bf0807240127p5226822atcd4a0711f1bc9c5c@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T12:42:49Z","receivedAt":"2008-07-24T12:42:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/23/08, Johannes Schindelin wrote:\n>\n> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> >\n> > > On 7/23/08, Johannes Schindelin wrote:\n> > >\n> > > > And with core.sparseCheckout you are at the whim of the user, \n> > > > since .git/config is _supposed_ to be user-editable.\n> > >\n> > > Well, whatever place. I chose .git/config because I did not want to \n> > > introduce a new config place. But then how about \n> > > .git/sparsecheckout?\n> >\n> > No, I did mean the index. This is an attribute of the index: either \n> > it is sparsely checked out or not. You can even have multiple indices \n> > (switching between them by setting GIT_INDEX_FILE) which have \n> > different prefixes.\n> \n> I don't think so. It's a mask for workdir, right? If you save it it \n> index, you can switch index and the prefix as well, but workdir only has \n> several subtrees that do not fit any other prefix than the original \n> prefix.\n\nAh, you adroitly avoided addressing the issue that the user can change the \nprefix without the index ever noticing.\n\nWell, in any case, if you do not agree that the prefix is really an \nattribute of the index, then there is nothing else I have to say on this \nseries.\n\nCiao,\nDscho\n"},{"id":"84713","messageId":"fcaeb9bf0807240629v6958014bpfa9aebde281ff57@mail.gmail.com","threadId":"14619","inReplyTo":"alpine.DEB.1.00.0807241340490.8986@racer","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T13:29:04Z","receivedAt":"2008-07-24T13:29:04Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nOn 7/24/08, Johannes Schindelin wrote:\n> > > No, I did mean the index. This is an attribute of the index: either\n> > > it is sparsely checked out or not. You can even have multiple indices\n> > > (switching between them by setting GIT_INDEX_FILE) which have\n> > > different prefixes.\n> >\n> > I don't think so. It's a mask for workdir, right? If you save it it\n> > index, you can switch index and the prefix as well, but workdir only has\n> > several subtrees that do not fit any other prefix than the original\n> > prefix.\n>\n>\n> Ah, you adroitly avoided addressing the issue that the user can change the\n> prefix without the index ever noticing.\n\nForgive my ignorance. I still do not get why index must notice prefix\nchange? The only reason I can think of is that we must make sure there\nwon't be any user-modification in index outside the prefix. But that\ncan be guarded from higher level (plumbings and porcelains) because\nindex is allowed to have modification outside sparse prefix\n(auto-merged entries).\n-- \nDuy\n"},{"id":"84714","messageId":"alpine.DEB.1.00.0807241443230.8986@racer","threadId":"14619","inReplyTo":"fcaeb9bf0807240629v6958014bpfa9aebde281ff57@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T13:44:18Z","receivedAt":"2008-07-24T13:44:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/24/08, Johannes Schindelin wrote:\n> > > > No, I did mean the index. This is an attribute of the index: \n> > > > either it is sparsely checked out or not. You can even have \n> > > > multiple indices (switching between them by setting \n> > > > GIT_INDEX_FILE) which have different prefixes.\n> > >\n> > > I don't think so. It's a mask for workdir, right? If you save it it \n> > > index, you can switch index and the prefix as well, but workdir \n> > > only has several subtrees that do not fit any other prefix than the \n> > > original prefix.\n> >\n> >\n> > Ah, you adroitly avoided addressing the issue that the user can change \n> > the prefix without the index ever noticing.\n> \n> Forgive my ignorance. I still do not get why index must notice prefix \n> change? The only reason I can think of is that we must make sure there \n> won't be any user-modification in index outside the prefix. But that can \n> be guarded from higher level (plumbings and porcelains) because index is \n> allowed to have modification outside sparse prefix (auto-merged \n> entries).\n\nWhy do you want to guard it from the outside? When the obvious fix is to \nput together what belongs together?\n\nHth,\nDscho\n"},{"id":"84715","messageId":"fcaeb9bf0807240650v6eab6ad4n63c39973b3b43658@mail.gmail.com","threadId":"14619","inReplyTo":"alpine.DEB.1.00.0807241443230.8986@racer","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T13:50:56Z","receivedAt":"2008-07-24T13:50:56Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/24/08, Johannes Schindelin wrote:\n> Hi,\n>\n> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n>\n>\n> > On 7/24/08, Johannes Schindelin wrote:\n> > > > > No, I did mean the index. This is an attribute of the index:\n> > > > > either it is sparsely checked out or not. You can even have\n> > > > > multiple indices (switching between them by setting\n> > > > > GIT_INDEX_FILE) which have different prefixes.\n> > > >\n> > > > I don't think so. It's a mask for workdir, right? If you save it it\n> > > > index, you can switch index and the prefix as well, but workdir\n> > > > only has several subtrees that do not fit any other prefix than the\n> > > > original prefix.\n> > >\n> > >\n> > > Ah, you adroitly avoided addressing the issue that the user can change\n> > > the prefix without the index ever noticing.\n> >\n> > Forgive my ignorance. I still do not get why index must notice prefix\n> > change? The only reason I can think of is that we must make sure there\n> > won't be any user-modification in index outside the prefix. But that can\n> > be guarded from higher level (plumbings and porcelains) because index is\n> > allowed to have modification outside sparse prefix (auto-merged\n> > entries).\n>\n>\n> Why do you want to guard it from the outside? When the obvious fix is to\n> put together what belongs together?\n\nOK. I am lost here. I do not know how putting sparse prefix and index\ntogether could fix \"it\" (I think you meant the index guarding). But we\nare in -rc period now, probably should not put too much time on this.\nI will take time to think about this.\n\n-- \nDuy\n"},{"id":"84734","messageId":"32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com","threadId":"14619","inReplyTo":"fcaeb9bf0807240650v6eab6ad4n63c39973b3b43658@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-24T16:22:32Z","receivedAt":"2008-07-24T16:22:32Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/24/08, Nguyen Thai Ngoc Duy wrote:\n> OK. I am lost here. I do not know how putting sparse prefix and index\n> together could fix \"it\" (I think you meant the index guarding).\n\nI think what Dscho is saying is simply that it's natural to put\ninformation about the currently-checked-out tree in the index, and\nunnatural to put it in the config.\n\nIf I switch branches, or checkout different versions, or git add, or\ngit rm, it all affects the index, never the config. The index stores\nthe attributes of which files are checked out, and can detect whether\nthose files are different from before. Choosing which subtrees to\ncheck out sounds a lot more like one of those operations than it does\nlike a configuration change.\n\nAlso, I don't know if git supports this right now, but I can imagine\nsituations where you'd want to have more than one index (and\nassociated working trees) sharing the exact same .git folder. It\nwould be fine to share the config between these parallel checkouts,\nbut you certainly couldn't share the index. And you probably wouldn't\nwant to check out exactly the same set of subtrees in every working\ntree.\n\nThe information required to do a checkout is in the index. And\n\"sparse checkout\" is all about checking out :)\n\nHave fun,\n\nAvery\n"},{"id":"84737","messageId":"alpine.DEB.1.00.0807241736050.8986@racer","threadId":"14619","inReplyTo":"32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-24T16:38:14Z","receivedAt":"2008-07-24T16:38:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Avery Pennarun wrote:\n\n> [a nice summary about why the index should know the sparse checkout \n> prefix]\n\nThanks.\n\n> Also, I don't know if git supports this right now, but I can imagine\n> situations where you'd want to have more than one index (and\n> associated working trees) sharing the exact same .git folder.\n\nIt is. And I already mentioned it. Note that it can make sense to work \non an index only, without ever touching a working directory.\n\nFor example, I do that a lot when importing projects that use \n\"tarball+patches\" for version control.\n\nCiao,\nDscho\n"},{"id":"84760","messageId":"loom.20080724T171151-310@post.gmane.org","threadId":"14619","inReplyTo":"fcaeb9bf0807240200x10a6a267h4c37e4566da967ba@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2008-07-24T17:59:38Z","receivedAt":"2008-07-24T17:59:38Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"Nguyen Thai Ngoc Duy gmail.com> writes:\n\n> This one is difficult (and may probably produce more intrusive patch).\n> Let's see what I can do.\n\nThis is not a high priority for me, so if the added\ndifficulty/intrusiveness means it would take longer for the sparse\ncheckout capability to make it into mainline git, then I would drop this\nrequest, or at least delay it until some later time.\n\n> > Second, I would want a capability to checkout and release directories\n> > incrementally, similar to how we do it in cvs. For example, I might do\n> > the following in cvs:\n> \n> You can do that with \"git checkout --path\" (non-recursive checkout aside):\n> \n> $ git checkout --path=A # checkout full A\n> $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only\n> $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too\n\nMy point was not that incremental checkout is impossible, just that it\nwould be easier if I didn't have to re-type the full path list again.\nSuppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,\nand I wanted to add a 10th directory (A/B10). It would be much easier\nto type something like\n\n$ cd A\n$ git checkout B10\n\ninstead of\n\n$ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10\n\n\nAnother thing I thought of, which I'm not sure if it's sensible or not,\nis to make sparse checkout a persistent branch attribute by creating a\n.gitpaths (or whatever) file containing a list of directories that\nshould be checked out. This would be analogous to the .gitmodules file.\nThe .gitpaths file could then be checked in, and applied automatically\nany time the user checks out a branch containing such file. This is\njust an idea for discussion, not a feature request.\n\nJames\n"},{"id":"84776","messageId":"fcaeb9bf0807241159u6c296156q93d45c7e87dcce9a@mail.gmail.com","threadId":"14619","inReplyTo":"32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T18:59:57Z","receivedAt":"2008-07-24T18:59:57Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/24/08, Avery Pennarun wrote:\n> On 7/24/08, Nguyen Thai Ngoc Duy wrote:\n> > OK. I am lost here. I do not know how putting sparse prefix and index\n> > together could fix \"it\" (I think you meant the index guarding).\n>\n> [snip]\n>\n> The information required to do a checkout is in the index. And\n> \"sparse checkout\" is all about checking out :)\n\nThat was better Dscho's questions ;) Thanks for the enlightenment.\n-- \nDuy\n"},{"id":"84786","messageId":"200807242201.23991.jnareb@gmail.com","threadId":"14619","inReplyTo":"fcaeb9bf0807240358l6584c063u85179196bd6db30a@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-24T20:01:23Z","receivedAt":"2008-07-24T20:01:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> On 7/24/08, Jakub Narebski wrote:\n> >\n> > Second, I think you can simply special case .git* files (.gitignore,\n> > .gitattributes, .gitmodules), and always check them out for all\n> > intermediate directories (unless configured otherwise, of course).\n> > So for example if you have the following directory structure:\n> >\n> > A/.gitignore\n> > A/a\n> > A/B1/.gitignore\n> > A/B1/b\n> > A/B2/.gitignore\n> > A/B2/c\n> >\n> > and you are checking out only subdirectory 'B1' (and all files in it;\n> > if subdirectories are checked out recursively it depends on\n> > configuration), and if for example there is .gitignore in every\n> > directory, then checked out tree would look like this:\n> >\n> > A/.gitignore\n> > A/B1/.gitignore\n> > A/B1/b\n> >\n> > The ability to do this is one of advantages of 'sparse' checkout over\n> > 'subtree' checkout.\n> \n> Or teach git to use index version of those files. Or collect all those\n> files, combine them and put the result to .git/info/exclude (and\n> similar places). Anyway well organized repos won't have this problem.\n> \n> Checking some files out as read-only (like this case) may be\n> interesting. Though I do not how much complicated it can be.\n\nI think teaching git to use index version of .git* files (.gitignore,\n.gitattributes, .gitmodules) would be much more work than adding\ndefault rule that .git* files in leading directories are by default\nchecked out, just like leading directories are checked out. This\nwould limit modifying git code, I think, and chances for errors.\n\nHaving \"leading\" directories and files read-only would be a good idea,\nI think.\n\nI don't understand the sentence \"well organized repos won't have this\nproblem\". I think well organized repos _would_ have this problem,\nbecause of maintained and distributed top-level .gitignore and\n.gitattributes.\n\nP.S. I hope that 'sparse checkout' feature would be ready for 1.7.0\n-- \nJakub Narebski\nPoland\n"},{"id":"84804","messageId":"fcaeb9bf0807241621y60b0341ej8f9f3b591ef12baf@mail.gmail.com","threadId":"14619","inReplyTo":"200807242201.23991.jnareb@gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T23:21:17Z","receivedAt":"2008-07-24T23:21:17Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/25/08, Jakub Narebski wrote:\n> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 7/24/08, Jakub Narebski wrote:\n> > >\n> > > Second, I think you can simply special case .git* files (.gitignore,\n> > > .gitattributes, .gitmodules), and always check them out for all\n> > > intermediate directories (unless configured otherwise, of course).\n> > > So for example if you have the following directory structure:\n> > >\n> > > A/.gitignore\n> > > A/a\n> > > A/B1/.gitignore\n> > > A/B1/b\n> > > A/B2/.gitignore\n> > > A/B2/c\n> > >\n> > > and you are checking out only subdirectory 'B1' (and all files in it;\n> > > if subdirectories are checked out recursively it depends on\n> > > configuration), and if for example there is .gitignore in every\n> > > directory, then checked out tree would look like this:\n> > >\n> > > A/.gitignore\n> > > A/B1/.gitignore\n> > > A/B1/b\n> > >\n> > > The ability to do this is one of advantages of 'sparse' checkout over\n> > > 'subtree' checkout.\n> >\n> > Or teach git to use index version of those files. Or collect all those\n> > files, combine them and put the result to .git/info/exclude (and\n> > similar places). Anyway well organized repos won't have this problem.\n> >\n> > Checking some files out as read-only (like this case) may be\n> > interesting. Though I do not how much complicated it can be.\n>\n>\n> I think teaching git to use index version of .git* files (.gitignore,\n> .gitattributes, .gitmodules) would be much more work than adding\n> default rule that .git* files in leading directories are by default\n> checked out, just like leading directories are checked out. This\n> would limit modifying git code, I think, and chances for errors.\n>\n> Having \"leading\" directories and files read-only would be a good idea,\n> I think.\n>\n> I don't understand the sentence \"well organized repos won't have this\n> problem\". I think well organized repos _would_ have this problem,\n> because of maintained and distributed top-level .gitignore and\n> .gitattributes.\n\nI wrote that with svn repos in mind. If those repos are to be\npartially checked out, .svnignore would be in subdirectories rather\nthan at toplevel. Anyway that may not be true.\n\n> P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0\n>\n> --\n> Jakub Narebski\n> Poland\n>\n\n\n-- \nDuy\n"},{"id":"84805","messageId":"fcaeb9bf0807241623m3fbd476dyc41990d8ef0888e6@mail.gmail.com","threadId":"14619","inReplyTo":"loom.20080724T171151-310@post.gmane.org","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-07-24T23:23:47Z","receivedAt":"2008-07-24T23:23:47Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/25/08, James Pickens wrote:\n> > You can do that with \"git checkout --path\" (non-recursive checkout aside):\n> >\n> > $ git checkout --path=A # checkout full A\n> > $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only\n> > $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too\n>\n>\n> My point was not that incremental checkout is impossible, just that it\n> would be easier if I didn't have to re-type the full path list again.\n> Suppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,\n> and I wanted to add a 10th directory (A/B10). It would be much easier\n> to type something like\n>\n> $ cd A\n> $ git checkout B10\n>\n> instead of\n>\n> $ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10\n\n\"git checkout B10\" form has already been taken. How about \"git\ncheckout --add-path\" and \"git checkout --remove-path\"?\n-- \nDuy\n"},{"id":"84808","messageId":"loom.20080724T233753-857@post.gmane.org","threadId":"14619","inReplyTo":"fcaeb9bf0807241623m3fbd476dyc41990d8ef0888e6@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2008-07-24T23:38:48Z","receivedAt":"2008-07-24T23:38:48Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"Nguyen Thai Ngoc Duy gmail.com> writes:\n\n> \"git checkout B10\" form has already been taken. How about \"git\n> checkout --add-path\" and \"git checkout --remove-path\"?\n\nThat would be fine. The specific syntax is not that important to me, as long as\nthe capability exists.\n\nJames\n"},{"id":"84813","messageId":"alpine.DEB.1.00.0807250205270.4140@eeepc-johanness","threadId":"14619","inReplyTo":"200807242201.23991.jnareb@gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-25T00:07:25Z","receivedAt":"2008-07-25T00:07:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Jul 2008, Jakub Narebski wrote:\n\n> I think teaching git to use index version of .git* files (.gitignore,\n> .gitattributes, .gitmodules) would be much more work than adding\n> default rule that .git* files in leading directories are by default\n> checked out, just like leading directories are checked out.\n\n\"Teaching\" Git that would also directly contradict Git's primary motto: \n\"Content is king\".\n\nOh, by some convoluted reasoning you could argue that \"content\" hidden \nsomewhere else than the working directory is \"content\", but nobody in her \nright mind would buy into that.\n\nCiao,\nDscho\n"},{"id":"84889","messageId":"32541b130807250753j1071639ao9313a8acad9f4183@mail.gmail.com","threadId":"14619","inReplyTo":"fcaeb9bf0807241621y60b0341ej8f9f3b591ef12baf@mail.gmail.com","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-25T14:53:54Z","receivedAt":"2008-07-25T14:53:54Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/24/08, Nguyen Thai Ngoc Duy wrote:\n> I wrote that with svn repos in mind. If those repos are to be\n> partially checked out, .svnignore would be in subdirectories rather\n> than at toplevel. Anyway that may not be true.\n\nAs far as I know, this is a misstatement of how svn works. It uses\nsvn:ignore properties, not .svnignore files, and they don't apply\nrecursively, so this potential inconsistency wouldn't happen with svn.\n Of course, in the name of this consistency, svn gave up recursive\nignores.\n\nSo anyway, back on topic, the definition of a \"well-organized\nrepository\" is different wth git than with svn for this reason. I\nwould certainly expect most well-organized git repositories to have a\ntoplevel .gitignore for the most common stuff.\n\nHave fun,\n\nAvery\n"},{"id":"86091","messageId":"20080803183749.GA3482@efreet.light.src","threadId":"14619","inReplyTo":"alpine.DEB.1.00.0807231753240.8986@racer","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-03T18:37:49Z","receivedAt":"2008-08-03T18:37:49Z","isPatch":true,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello,\n\nsorry for replying to an old thread, but I am a bit puzzled here,\n\nOn Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:\n> On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> > On 7/23/08, Johannes Schindelin wrote:\n> > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n> > >\n> > > > So in short, sparse prefix will be stored in config, \n> > > > core.sparsecheckout.\n> > >\n> > > Do you really think the prefix should be stored anywhere else than the \n> > > index?\n> > >\n> > > With core.sparseCheckout you have to introduce a _sh*tload_ of config \n> > > loaders.\n> > >\n> > > And with core.sparseCheckout you are at the whim of the user, since \n> > > .git/config is _supposed_ to be user-editable.\n> > >\n> > > From a logical point of view, I'd say that the sparse prefix has \n> > > nothing to do with the \"configuration\" of the local repository.\n> > \n> > Well, whatever place. I chose .git/config because I did not want to \n> > introduce a new config place. But then how about .git/sparsecheckout?\n> \n> No, I did mean the index. This is an attribute of the index: either it is \n> sparsely checked out or not. You can even have multiple indices \n> (switching between them by setting GIT_INDEX_FILE) which have different \n> prefixes.\n\nUm, but does the prefix we want to use depend on what files are physically\npresent in the tree? That would however imply that it's /not/ an attribute of\nthe index, but the tree and therefore should be stored in a separate object.\n\nThe question whether it goes in the .git/config or .git/sparsecheckout is\nthan that of semantics -- if it's in .git/config, than user changes that by\nediting the file or git config and no other way, while if it's in\n.git/sparsecheckout, user changes it by running checkout with appropriate\narguments.\n\nBy the way, why is it *prefix*? Wouldn't a *path limit* be better?\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"86099","messageId":"alpine.DEB.1.00.0808032238170.9611@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"14619","inReplyTo":"20080803183749.GA3482@efreet.light.src","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-03T20:48:46Z","receivedAt":"2008-08-03T20:48:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 3 Aug 2008, Jan Hudec wrote:\n\n> On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:\n> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> > > On 7/23/08, Johannes Schindelin wrote:\n> > > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n> > > >\n> > > > > So in short, sparse prefix will be stored in config, \n> > > > > core.sparsecheckout.\n> > > >\n> > > > Do you really think the prefix should be stored anywhere else than \n> > > > the index?\n> > > >\n> > > > With core.sparseCheckout you have to introduce a _sh*tload_ of \n> > > > config loaders.\n> > > >\n> > > > And with core.sparseCheckout you are at the whim of the user, \n> > > > since .git/config is _supposed_ to be user-editable.\n> > > >\n> > > > From a logical point of view, I'd say that the sparse prefix has \n> > > > nothing to do with the \"configuration\" of the local repository.\n> > > \n> > > Well, whatever place. I chose .git/config because I did not want to \n> > > introduce a new config place. But then how about \n> > > .git/sparsecheckout?\n> > \n> > No, I did mean the index. This is an attribute of the index: either \n> > it is sparsely checked out or not. You can even have multiple indices \n> > (switching between them by setting GIT_INDEX_FILE) which have \n> > different prefixes.\n> \n> Um, but does the prefix we want to use depend on what files are \n> physically present in the tree?\n\nThe thing is: in a checkout, the flow of data is\n\n\tHEAD -> index -> worktree\n\nTo check in, the flow is exactly opposite.\n\nThere are also legal workflows where you do not work on the worktree at \nall.\n\nAnd there are legal workflows where you work with multiple \nindices/worktrees.\n\nNow, it appears pretty obvious to me that the logical thing is to tell the \n(current) index what is supposed to be checked out and what not.\n\nAfter all, a merge is done inside the index. And if the merge touches \nparts outside of the sparse checkout, it is natural to have the index know \nabout it.\n\nBecause the merge _has_ to complain then.\n\nIn any case, isn't it clearly the more elegant solution to just put the \ninformation into the index when you touch it _anyway_?\n\nI am really puzzled why people think it is a good idea to separate the \nfile metadata from the information what files were checked out to begin \nwith, as if they were totally independent.\n\nBecause they are not.\n\nCiao,\nDscho"},{"id":"86179","messageId":"fcaeb9bf0808040529q7583f65fj83780d2e818d39d2@mail.gmail.com","threadId":"14619","inReplyTo":"20080803183749.GA3482@efreet.light.src","subject":"Re: [RFC PATCH 00/12] Sparse checkout","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-08-04T12:29:24Z","receivedAt":"2008-08-04T12:29:24Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 8/4/08, Jan Hudec wrote:\n> Hello,\n>\n> sorry for replying to an old thread, but I am a bit puzzled here,\n>\n>\n> On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:\n> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:\n> > > On 7/23/08, Johannes Schindelin wrote:\n> > > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:\n> > > >\n> > > > > So in short, sparse prefix will be stored in config,\n> > > > > core.sparsecheckout.\n> > > >\n> > > > Do you really think the prefix should be stored anywhere else than the\n> > > > index?\n> > > >\n> > > > With core.sparseCheckout you have to introduce a _sh*tload_ of config\n> > > > loaders.\n> > > >\n> > > > And with core.sparseCheckout you are at the whim of the user, since\n> > > > .git/config is _supposed_ to be user-editable.\n> > > >\n> > > > From a logical point of view, I'd say that the sparse prefix has\n> > > > nothing to do with the \"configuration\" of the local repository.\n> > >\n> > > Well, whatever place. I chose .git/config because I did not want to\n> > > introduce a new config place. But then how about .git/sparsecheckout?\n> >\n> > No, I did mean the index. This is an attribute of the index: either it is\n> > sparsely checked out or not. You can even have multiple indices\n> > (switching between them by setting GIT_INDEX_FILE) which have different\n> > prefixes.\n>\n>\n> Um, but does the prefix we want to use depend on what files are physically\n> present in the tree? That would however imply that it's /not/ an attribute of\n> the index, but the tree and therefore should be stored in a separate object.\n>\n> The question whether it goes in the .git/config or .git/sparsecheckout is\n> than that of semantics -- if it's in .git/config, than user changes that by\n> editing the file or git config and no other way, while if it's in\n> .git/sparsecheckout, user changes it by running checkout with appropriate\n> arguments.\n\nPlease see the post Junio talked about narrow/sparse checkout [1].\nWith that approach (that is finer grain checkout than my approach), it\nbecomes clear that \"prefix\" is an attribute of index.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/90016/match=narrow+checkout\n\n> By the way, why is it *prefix*? Wouldn't a *path limit* be better?\n\nWell, yes \"path limiter\" seems a better term. But it's irrelevant now\nbecause this approach won't fly. I'm going to wait to see if anyone\ntakes the task as part of hackontest. Otherwise I will redo my series,\nusing assume unchanged bit.\n\n> --\n> Jan 'Bulb' Hudec \n>\n\n\n-- \nDuy\n"}]}