{"thread":{"id":"15925","subject":"Feedback outside of the user survey","startedAt":"2008-10-16T10:19:36Z","lastAt":"2008-10-21T07:24:12Z","messageCount":17,"participants":["Richard Hartmann","Jeff King","Garry Dolley","Christian Jaeger","Andreas Ericsson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93180","messageId":"2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com","threadId":"15925","inReplyTo":null,"subject":"Feedback outside of the user survey","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T10:19:36Z","receivedAt":"2008-10-16T10:19:36Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\nunfortunately, I did not know there was a survey, so I did not\nparticipate in it.\n\nI still want to give some feedback from my experiences with\ngit.\nFrom browsing the results [1] of said survey, I see one\nrequest being made a lot of times. It's basically my main\ngripe with git, as well :)\n\ngit can do a lot of things, but, as a new user, you are never\nquite sure where to start. Docs are geared towards advanced\nusers (which is fine), but there is no easy entry point (which\nis bad).\n\nI would suggest three approaches to fix this:\n\n1) A table/An overview along the lines of \"So, you are used to\nfoo and that is how you do it in git.\"\nFor example \"What is the equivalent of svn co\" (yes, that is an\neasy one ;). This should not be limited to things git can do.\nsvn's ability to pull a subdirectory, which is, ttbomk, lacking\nin git, should be included, as well. I am sure there are other\nexamples [2].\n\n2) A use case repository. \"So you want to merge two\nbranches\", etc. This would be a good place to explain the\ndifferent ways git offers to do stuff, as well.\n\n3) A tutorial. It does not even have to be as sophisticated\nas vimtutor. A simple text file specifying steps to do stuff\nwould be enough.\n\n\nThanks,\nRichard\n\n[1] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.33.1.7.1\n[2] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.14.1.7.1\n"},{"id":"93183","messageId":"20081016102835.GC20762@sigill.intra.peff.net","threadId":"15925","inReplyTo":"2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com","subject":"Re: Feedback outside of the user survey","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-16T10:28:35Z","receivedAt":"2008-10-16T10:28:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 16, 2008 at 12:19:36PM +0200, Richard Hartmann wrote:\n\n> 1) A table/An overview along the lines of \"So, you are used to\n> foo and that is how you do it in git.\"\n> For example \"What is the equivalent of svn co\" (yes, that is an\n> easy one ;). This should not be limited to things git can do.\n\nHow about:\n\n  Git - SVN Crash Course\n  http://git.or.cz/course/svn.html\n\n> 2) A use case repository. \"So you want to merge two\n> branches\", etc. This would be a good place to explain the\n> different ways git offers to do stuff, as well.\n\nHow about:\n\n  Git User's Manual\n  http://www.kernel.org/pub/software/scm/git/docs/user-manual.html\n\n(though I do think a user-contributed \"recipe\" database might be useful.\nMaybe such a thing even exists already and I don't know about it).\n\n> 3) A tutorial. It does not even have to be as sophisticated\n> as vimtutor. A simple text file specifying steps to do stuff\n> would be enough.\n\nHow about:\n\n  The Git Tutorial\n  http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html\n\nIs there something about these that doesn't meet your criteria? Or did\nyou not know about them (in which case, maybe we need to be more\nprominently pointing to them)?\n\n-Peff\n"},{"id":"93184","messageId":"2d460de70810160408x784a657fte418d41dd6a06d7f@mail.gmail.com","threadId":"15925","inReplyTo":"20081016102835.GC20762@sigill.intra.peff.net","subject":"Re: Feedback outside of the user survey","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T11:08:06Z","receivedAt":"2008-10-16T11:08:06Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Thu, Oct 16, 2008 at 12:28, Jeff King <peff@peff.net> wrote:\n\n> Is there something about these that doesn't meet your criteria? Or did\n> you not know about them (in which case, maybe we need to be more\n> prominently pointing to them)?\n\nIn best slapstick fashion, I found the pages you mentioned in 1) and 3)\nafter sending off my email. Maybe they did not exist back when I last\nlooked, maybe they are easier to find now, maybe I was too stupid to\nlook, back then.\nIn any case, those two fit my needs nicely. In fact, I would have said\nas much on this list if I had not become stuck in reading said docs :)\n\nAs to the resource you mention in 2), it is nice, but it does not fit\nexactly to what I had in mind. You have a lot of snippets and single\nsteps, which is fine. What I was imagining was more like a use case\n& workflow-driven layout.\nA basic or complex task could give a short overview of steps, all of\nwhich would be hyperlinked to detailed explanations. As a lot (more)\ndocumentation seems to exist since I last gave git a serious try,\nthis is probably mainly a work of coming up with workflows and\nlinking to the correct places, not so much of writing any actual new\ntext.\n\n\nAnd yes, I think the fact that these newbie-friendly docs exist these\ndays should be pushed more agressively. As you can see from the\nlinks in my initial mail, a _lot_ of people have the same\nmisinformation I used to have. That will mainly be due to old\nknowledge, but the situation exists. Worse, those people will warn\nothers about the lack of starter-level docs, making more people\nshun git for all the wrong reasons.\n\nAn easy step in this direction might be to _prominently_ display\ndirect links to the newbie docs on the entry points, for most users.\nI.e. the main site [1] and the wiki [2] along with the FAQ. I would\nedit the wiki myself, but I could not find\nMoinMaster:MoinPagesEditorGroup nor MoinMaster anywhere\nin said wiki, thus decided to heed the warning & not edit at all.\n\n\nRichard\n\n[1] http://git.or.cz/\n[2] http://git.or.cz/gitwiki\n"},{"id":"93190","messageId":"20081016115628.GA24836@garry-x300.arpnetworks.com","threadId":"15925","inReplyTo":"2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com","subject":"Re: Feedback outside of the user survey","fromName":"Garry Dolley","fromEmail":"gdolley@arpnetworks.com","sentAt":"2008-10-16T11:56:28Z","receivedAt":"2008-10-16T11:56:28Z","isPatch":false,"sender":{"key":"gdolley@ucla.edu","avatar":"https://gravatar.com/avatar/b9ca98e2d5fd3a993ad695e8315f078b7ae364d2d1b637a6adecf8953a034dd2?d=mp&s=160"},"body":"On Thu, Oct 16, 2008 at 12:19:36PM +0200, Richard Hartmann wrote:\n> svn's ability to pull a subdirectory, which is, ttbomk, lacking\n> in git, should be included, as well. I am sure there are other\n> examples [2].\n\nPulling a subdirectory with svn is possible because svn (and others\nlike it) tracks your files and directories.  Git, on the other hand,\ntracks the _content_ of the files in the repo.  The information that\nGit presents (logs, diff's, file contents, etc.) is built from\nobjects that are created from content you add to the repo.\n\nPulling a subdirectory and thereby excluding the files that make up the\ncontent that git used to build its structures in the first place, is\nsomething that I don't think would make sense.\n\nI know from an external point of view, it seems pulling a subdir\nwouldn't be a big deal; but if you look at git internals, you start\nto realize why it's an option that isn't on the table.\n\nSomeone please correct me if I'm wrong here.\n\n-- \nGarry Dolley\nARP Networks, Inc.\nhttp://scie.nti.st\nLos Angeles County REACT, Unit 336\nWQGK336\n"},{"id":"93196","messageId":"2d460de70810160618u1803375aj913145a5060e5308@mail.gmail.com","threadId":"15925","inReplyTo":"20081016115628.GA24836@garry-x300.arpnetworks.com","subject":"Re: Feedback outside of the user survey","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T13:18:32Z","receivedAt":"2008-10-16T13:18:32Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:\n\n> I know from an external point of view, it seems pulling a subdir\n> wouldn't be a big deal; but if you look at git internals, you start\n> to realize why it's an option that isn't on the table.\n\nThat's my understanding as well. And you can simply branch\nout a subdir when you want to work on it.\nI am not saying this should be changed, just that it should\nbe mention in The Big Overview.\n\n\nRichard\n"},{"id":"93239","messageId":"48F7A4F8.2080600@jaeger.mine.nu","threadId":"15925","inReplyTo":"2d460de70810160618u1803375aj913145a5060e5308@mail.gmail.com","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-16T20:32:56Z","receivedAt":"2008-10-16T20:32:56Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Richard Hartmann wrote:\n> On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:\n>\n>   \n>> I know from an external point of view, it seems pulling a subdir\n>> wouldn't be a big deal; but if you look at git internals, you start\n>> to realize why it's an option that isn't on the table.\n>>     \n\nHm, I don't see a fundamental technical problem which would prevent one \nfrom implementing the ability to checkout only a subdirectory into the \nworking directory (i.e. to add options to Git to make it reflect the \nworking directory as being a subdirectory of what is in Git's database). \nAt this level I don't see anything inherently different from SVN--except \nmaybe for directory renames: if someone else is renaming the directory \nyou've checked out, what should happend with your checkout? Git's \nfilebased rename tracking would just lead to everything vanishing from \nyour checkout. I don't know what happens in SVN, maybe it keeps track of \nthe directory rename and still sends you the changes of the directory \nyou've checked out even if it has now a different name on the server?\n\nAnyway, an unavoidable difference is that you have to always clone the \nwhole Git *database*. With SVN the database stays on the server, with \nGit it is being cloned. Just as I expect SVN to need the whole database \nto be able to work (tracking renames across directories etc.), Git needs \nthe whole database too. So implementing subdirectory workingdir \ncheckouts wouldn't help reduce the bandwidth and storage necessary for \ngetting at the database.\n\n>\n> That's my understanding as well. And you can simply branch\n> out a subdir when you want to work on it.\n>   \n\nI guess what you are referring to is\n\n $ git clone git://foo.com/bar.git\n $ cd bar\n $ rm -rf *\n $ git checkout somesubdir\n\nNow you've got only somesubdir/ below bar/. This solves the rename \nproblem insofar, as somesubdir will just be renamed if someone else \ncommits a \"git mv somesubdir somethingelse\" and you pull that change. \nBut there's also another caveat: \"git status\" will of course report the \nother files as deleted, which is an accident waiting to happen when you \nnext run \"git commit -a\".\n\n(In any case, this is just thinking louder than I deserve, as there's no \ncode at all in Git written by me.)\n\nChristian.\n"},{"id":"93368","messageId":"20081018134906.GA13894@garry-thinkpad.arpnetworks.com","threadId":"15925","inReplyTo":"48F7A4F8.2080600@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Garry Dolley","fromEmail":"gdolley@arpnetworks.com","sentAt":"2008-10-18T13:49:07Z","receivedAt":"2008-10-18T13:49:07Z","isPatch":false,"sender":{"key":"gdolley@ucla.edu","avatar":"https://gravatar.com/avatar/b9ca98e2d5fd3a993ad695e8315f078b7ae364d2d1b637a6adecf8953a034dd2?d=mp&s=160"},"body":"On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:\n> Hm, I don't see a fundamental technical problem which would prevent one \n> from implementing the ability to checkout only a subdirectory into the \n> working directory (i.e. to add options to Git to make it reflect the \n> working directory as being a subdirectory of what is in Git's database). At \n> this level I don't see anything inherently different from SVN--except maybe \n> for directory renames: if someone else is renaming the directory you've \n> checked out, what should happend with your checkout? Git's filebased rename \n> tracking would just lead to everything vanishing from your checkout. I \n> don't know what happens in SVN, maybe it keeps track of the directory \n> rename and still sends you the changes of the directory you've checked out \n> even if it has now a different name on the server?\n>\n> Anyway, an unavoidable difference is that you have to always clone the \n> whole Git *database*. With SVN the database stays on the server, with Git \n> it is being cloned. Just as I expect SVN to need the whole database to be \n> [...]\n\nRight, but I think cloning the entire git database just to get a\nsubdir is a fundamental technical problem.  It's no different than\ngit-clone + checkout + rm -rf <what I don't want in working tree>\n\nIn that sense, git already has support for cloning subdirectories,\nwhich is why I don't think this method applies to what the original\npost author meant when they referred to \"support for cloning sub\ndirectories\".\n\n:)\n\n-- \nGarry Dolley\nARP Networks, Inc.\nhttp://scie.nti.st\nLos Angeles County REACT, Unit 336\nWQGK336\n"},{"id":"93369","messageId":"48F9EC2B.2010200@jaeger.mine.nu","threadId":"15925","inReplyTo":"20081018134906.GA13894@garry-thinkpad.arpnetworks.com","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-18T14:01:15Z","receivedAt":"2008-10-18T14:01:15Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Garry Dolley wrote:\n> On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:\n>   \n>> Hm, I don't see a fundamental technical problem which would prevent one \n>> from implementing the ability to checkout only a subdirectory into the \n>> working directory (i.e. to add options to Git to make it reflect the \n>> working directory as being a subdirectory of what is in Git's database). At \n>> this level I don't see anything inherently different from SVN--except maybe \n>> for directory renames: if someone else is renaming the directory you've \n>> checked out, what should happend with your checkout? Git's filebased rename \n>> tracking would just lead to everything vanishing from your checkout. I \n>> don't know what happens in SVN, maybe it keeps track of the directory \n>> rename and still sends you the changes of the directory you've checked out \n>> even if it has now a different name on the server?\n>>\n>> Anyway, an unavoidable difference is that you have to always clone the \n>> whole Git *database*. With SVN the database stays on the server, with Git \n>> it is being cloned. Just as I expect SVN to need the whole database to be \n>> [...]\n>>     \n>\n> Right, but I think cloning the entire git database just to get a\n> subdir is a fundamental technical problem.  It's no different than\n> git-clone + checkout + rm -rf <what I don't want in working tree>\n>   \n\nWe're in \"violent agreement\" here.\n\n> In that sense, git already has support for cloning subdirectories,\n> which is why I don't think this method applies to what the original\n> post author meant when they referred to \"support for cloning sub\n> directories\".\n>   \n\nI just think it's worth pointing out the difference between the working \ndir and the database. It should be as easy to implement checking out \nsubdirectories in Git as it was in SVN (except, again, that, iff \ndirectory renames should be tracked, some code would have to be written \nto find out about directory renames, which SVN solves in a simpler way \nby just requiring that the user specifies renames explicitely). It's \nworth pointing out that working directory checkouts and database cloning \nare separate operatoins and it's only the database cloning which is, per \ndefinition (as it is a distributed VCS) different from SVN.\n\n> :)\n>   \n\nIf you really wanted, I suppose you could additionally look into \nimplementing a kind of shallow cloning that only copies objects over the \nwire which are necessary for representing the subdirectory you're \ninterested in.\n\nChristian.\n"},{"id":"93487","messageId":"48FC55F9.3060509@op5.se","threadId":"15925","inReplyTo":"48F9EC2B.2010200@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-20T09:57:13Z","receivedAt":"2008-10-20T09:57:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Christian Jaeger wrote:\n> Garry Dolley wrote:\n>> On Thu, Oct 16, 2008 at 10:32:56PM +0200, Christian Jaeger wrote:\n>>  \n>>> Hm, I don't see a fundamental technical problem which would prevent \n>>> one from implementing the ability to checkout only a subdirectory \n>>> into the working directory (i.e. to add options to Git to make it \n>>> reflect the working directory as being a subdirectory of what is in \n>>> Git's database). At this level I don't see anything inherently \n>>> different from SVN--except maybe for directory renames: if someone \n>>> else is renaming the directory you've checked out, what should \n>>> happend with your checkout? Git's filebased rename tracking would \n>>> just lead to everything vanishing from your checkout. I don't know \n>>> what happens in SVN, maybe it keeps track of the directory rename and \n>>> still sends you the changes of the directory you've checked out even \n>>> if it has now a different name on the server?\n>>>\n>>> Anyway, an unavoidable difference is that you have to always clone \n>>> the whole Git *database*. With SVN the database stays on the server, \n>>> with Git it is being cloned. Just as I expect SVN to need the whole \n>>> database to be [...]\n>>>     \n>>\n>> Right, but I think cloning the entire git database just to get a\n>> subdir is a fundamental technical problem.  It's no different than\n>> git-clone + checkout + rm -rf <what I don't want in working tree>\n>>   \n> \n> We're in \"violent agreement\" here.\n> \n>> In that sense, git already has support for cloning subdirectories,\n>> which is why I don't think this method applies to what the original\n>> post author meant when they referred to \"support for cloning sub\n>> directories\".\n>>   \n> \n> I just think it's worth pointing out the difference between the working \n> dir and the database. It should be as easy to implement checking out \n> subdirectories in Git as it was in SVN (except, again, that, iff \n> directory renames should be tracked, some code would have to be written \n> to find out about directory renames, which SVN solves in a simpler way \n> by just requiring that the user specifies renames explicitely). It's \n> worth pointing out that working directory checkouts and database cloning \n> are separate operatoins and it's only the database cloning which is, per \n> definition (as it is a distributed VCS) different from SVN.\n> \n>> :)\n>>   \n> \n> If you really wanted, I suppose you could additionally look into \n> implementing a kind of shallow cloning that only copies objects over the \n> wire which are necessary for representing the subdirectory you're \n> interested in.\n> \n\nSo what do you do when one such commit also affects something outside\nthe subdirectory?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"93498","messageId":"48FC9927.5030903@jaeger.mine.nu","threadId":"15925","inReplyTo":"48FC55F9.3060509@op5.se","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-20T14:43:51Z","receivedAt":"2008-10-20T14:43:51Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Andreas Ericsson wrote:\n> Christian Jaeger wrote:\n>> If you really wanted, I suppose you could additionally look into \n>> implementing a kind of shallow cloning that only copies objects over \n>> the wire which are necessary for representing the subdirectory you're \n>> interested in.\n>>\n>\n> So what do you do when one such commit also affects something outside\n> the subdirectory?\n\nYou haven't said what you mean with \"affect\".\n\nSince the point is that you do not want to see any effect to be made nor \ndescribed if it is about something outside the subdirectory, the program \nwould just not look at those?\n\nDid you mean, new commits to be made from changed subdirectory contents? \nThe stuff outside the subdirectory would just be kept the same and thus \nagain doesn't need to be present locally.\n\nDid you mean merging branches where one or more of the branches have \nchanges outside the working directory? As long as the changes from the \nbranches don't touch any of the same files (outside the \nsubworkingdirectory), there's no need to fetch the files' contents, the \nprogram is only interested in the changes in the directory listings \n(thus directory objects). Now if there *are* changes to the same files \n(and outside the subworkingdirectory), the program would certainly need \nto fetch those contents, too, to be able to create the new contents. \nWould it require a place in the working directory? Yes if there are \nconflicts which need to be resolved manually, since it needs a place to \nput the conflicts to ask the user to resolve.  So I guess it boils down \nto SVN having a different notion of what a merge entails?\n\nChristian.\n"},{"id":"93517","messageId":"48FC9D87.3010303@op5.se","threadId":"15925","inReplyTo":"48FC9927.5030903@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-20T15:02:31Z","receivedAt":"2008-10-20T15:02:31Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Christian Jaeger wrote:\n> Andreas Ericsson wrote:\n>> Christian Jaeger wrote:\n>>> If you really wanted, I suppose you could additionally look into \n>>> implementing a kind of shallow cloning that only copies objects over \n>>> the wire which are necessary for representing the subdirectory you're \n>>> interested in.\n>>>\n>>\n>> So what do you do when one such commit also affects something outside\n>> the subdirectory?\n> \n> You haven't said what you mean with \"affect\".\n> \n\nI mean \"how would you handle a commit (and its tree-object) that updates\nall Makefiles in, for example, the Linux kernel project?\". Those files\nare spread far and wide, and you'd want that change to *your* tree, but\ngetting it into your tree either means you need to rewrite the tree (and\nthereby the commit) itself to get rid of uninteresting blob's from the\ntree, and you'd also have to prune the tree to not reveal the directory\nlayout of the rest of the repository.\n\nI take it parentage could be resolved by a ridiculously large grafts-file.\n\nWhat you'd end up with wouldn't be a git repository at all anymore. It\nwould be a \"stump\", as it'd be missing large parts of the tree entirely.\nI'm unsure just how much you'd have to compute to be able to use such a\nstump to incorporate your changes with other users again, but I doubt it\nwould be trivial to implement. Good thing it's not my itch, really.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"93507","messageId":"48FCA1BC.3060300@jaeger.mine.nu","threadId":"15925","inReplyTo":"48FC9D87.3010303@op5.se","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-20T15:20:28Z","receivedAt":"2008-10-20T15:20:28Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Andreas Ericsson wrote:\n> Christian Jaeger wrote:\n>> Andreas Ericsson wrote:\n>>> Christian Jaeger wrote:\n>>>> If you really wanted, I suppose you could additionally look into \n>>>> implementing a kind of shallow cloning that only copies objects \n>>>> over the wire which are necessary for representing the subdirectory \n>>>> you're interested in.\n>>>>\n>>>\n>>> So what do you do when one such commit also affects something outside\n>>> the subdirectory?\n>>\n>> You haven't said what you mean with \"affect\".\n>>\n>\n> I mean \"how would you handle a commit (and its tree-object) that updates\n> all Makefiles in, for example, the Linux kernel project?\". Those files\n> are spread far and wide, and you'd want that change to *your* tree, but\n> getting it into your tree either means you need to rewrite the tree (and\n> thereby the commit) itself to get rid of uninteresting blob's from the\n> tree, and you'd also have to prune the tree to not reveal the directory\n> layout of the rest of the repository.\n\nYou have said \"either\" but not \"or\".\n\n> I take it parentage could be resolved by a ridiculously large \n> grafts-file.\n\nHm, not sure whether you mean to rescue the situation with rewritten \ncommits here -- but hell no, I certainly don't mean to have different \ncommit objects for different clones/checkouts.\n\n> What you'd end up with wouldn't be a git repository at all anymore. It\n> would be a \"stump\", as it'd be missing large parts of the tree entirely.\n\nThat was my point, yes.\n\n> I'm unsure just how much you'd have to compute to be able to use such a\n> stump to incorporate your changes with other users again, but I doubt it\n> would be trivial to implement. Good thing it's not my itch, really.\n\nI've been suggesting it to Garry :)\n\nMaybe whoever writes up something on the wiki regarding subdirectory \ncheckouts in SVN versus Git could still care about what the \"fundamental \ntechnical\" limits are versus what the current implementation (or \npracticalness) imposes. It will be both a more enlightening and \npotentially more future-proof explanation then.\n\nChristian.\n"},{"id":"93506","messageId":"48FCADA0.4020008@op5.se","threadId":"15925","inReplyTo":"48FCA1BC.3060300@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-20T16:11:12Z","receivedAt":"2008-10-20T16:11:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Christian Jaeger wrote:\n> Andreas Ericsson wrote:\n>> Christian Jaeger wrote:\n>>> Andreas Ericsson wrote:\n>>>> Christian Jaeger wrote:\n>>>>> If you really wanted, I suppose you could additionally look into \n>>>>> implementing a kind of shallow cloning that only copies objects \n>>>>> over the wire which are necessary for representing the subdirectory \n>>>>> you're interested in.\n>>>>>\n>>>>\n>>>> So what do you do when one such commit also affects something outside\n>>>> the subdirectory?\n>>>\n>>> You haven't said what you mean with \"affect\".\n>>>\n>>\n>> I mean \"how would you handle a commit (and its tree-object) that updates\n>> all Makefiles in, for example, the Linux kernel project?\". Those files\n>> are spread far and wide, and you'd want that change to *your* tree, but\n>> getting it into your tree either means you need to rewrite the tree (and\n>> thereby the commit) itself to get rid of uninteresting blob's from the\n>> tree, and you'd also have to prune the tree to not reveal the directory\n>> layout of the rest of the repository.\n> \n> You have said \"either\" but not \"or\".\n\n\"or end up transferring all objects on the wire anyway\".\n\n> \n>> I take it parentage could be resolved by a ridiculously large \n>> grafts-file.\n> \n> Hm, not sure whether you mean to rescue the situation with rewritten \n> commits here -- but hell no, I certainly don't mean to have different \n> commit objects for different clones/checkouts.\n> \n\nThen you'll be transferring all objects over the wire anyway, so there\ngoes that idea.\n\n>> What you'd end up with wouldn't be a git repository at all anymore. It\n>> would be a \"stump\", as it'd be missing large parts of the tree entirely.\n> \n> That was my point, yes.\n> \n\nThat's partially implemented, I think (google for Nguy (or something, I'm\nnot very god with asian names), but your original suggestion said to save\non transferring objects from one machine to another, which will play poorly\nwith git's object database and which you're now arguing against.\n\nPlease make up your mind.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"93541","messageId":"48FCB87B.1080207@jaeger.mine.nu","threadId":"15925","inReplyTo":"48FCADA0.4020008@op5.se","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-20T16:57:31Z","receivedAt":"2008-10-20T16:57:31Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Andreas Ericsson wrote:\n> Christian Jaeger wrote:\n>> Hm, not sure whether you mean to rescue the situation with rewritten \n>> commits here -- but hell no, I certainly don't mean to have different \n>> commit objects for different clones/checkouts.\n>>\n>\n> Then you'll be transferring all objects over the wire anyway\n\nWhy? Again, care to differentiate between technical feasibility and \ncurrent implementation.\n\nI did make a list of cases in my pre-previous email which tried to go \nthrough the implications.\n\n>>> What you'd end up with wouldn't be a git repository at all anymore. It\n>>> would be a \"stump\", as it'd be missing large parts of the tree \n>>> entirely.\n>>\n>> That was my point, yes.\n>>\n>\n> That's partially implemented, I think (google for Nguy (or something, I'm\n> not very god with asian names),\n\nThat's not enough information for me to find what you've had in mind. \n\"stump Nguy site:marc.info\" doesn't yield a result with Google.\n\n> but your original suggestion said to save\n> on transferring objects from one machine to another, \n\nYes\n\n> which will play poorly\n> with git's object database\n\nWhy, if we seem to already have agreed that the object database would be \na \"stump\"? It may play poorly with the current implementation of the \ndatabase maintainance code, but I don't see why it would play poorly \nwith the database's data structure design.\n\n> and which you're now arguing against.\n\nI don't get this part of the sentence.\n\nI did (3 mails ago) say, \"(one) could additionally look into \nimplementing a kind of shallow cloning\". When you said that the kind of \nrepository I'm \"arguing\" for would be a \"stump\", that sounded exactly \nwhat I've meant, in the same sense that a shallow clone creates a \nrepository that is missing part of the tree (or maybe DAG is a better \nterm). So I said \"That was my point, yes\", maybe I should have said \n\"That's what I've meant when I was saying a 'kind of shallow cloning'.\" \nOk? I might miss some fine points in the english language as I'm not a \nnative speaker.\n\n>\n> Please make up your mind.\n\nAbout what?\n\nDo you mean whether I want to implement the idea? Then no, I don't see \nmyself contributing any code for this. I certainly don't have a use case \npersonally where it would pay off. My motivation to contributing to this \nthread was to point out that there is, afaik, nothing inherent in the \nGit design (at least the database) which would absolutely prevent one \nfrom implementing subdirectory checkouts (including even saving on \nbandwith by doing some kind of shallow / stump / lazy cloning).\n\nChristian.\n"},{"id":"93530","messageId":"48FCC01B.8030709@jaeger.mine.nu","threadId":"15925","inReplyTo":"48FCB87B.1080207@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-20T17:30:03Z","receivedAt":"2008-10-20T17:30:03Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Christian Jaeger wrote:\n> Andreas Ericsson wrote:\n>> Christian Jaeger wrote:\n>>> Hm, not sure whether you mean to rescue the situation with rewritten \n>>> commits here -- but hell no, I certainly don't mean to have \n>>> different commit objects for different clones/checkouts.\n>>>\n>>\n>> Then you'll be transferring all objects over the wire anyway\n>\n> Why? Again, care to differentiate between technical feasibility and \n> current implementation.\n\nI think it was this detail:\n\n> ... lazy cloning\n\nwhich I have been leaving under the carpet in my previous mails; i.e. \nwhen doing merges, Git may need additional objects which haven't been \nfetched by just fetching the branches's subdirectory parts, so merges \ncan't generally be done offline anymore. This is certainly a departure \nfrom the current idea; and if you don't want to depart from that, then \nyes, you'd need basically the whole database in advance or merges \nwouldn't be possible. So I think I understand why you said \"Then you'll \nbe transferring all objects over the wire anyway\", you did assume that \nthere would be no such thing as on-demand / lazy fetching of missing \nobjects.\n\nChristian.\n"},{"id":"93559","messageId":"7viqrm3n53.fsf@gitster.siamese.dyndns.org","threadId":"15925","inReplyTo":"48FCB87B.1080207@jaeger.mine.nu","subject":"Re: Feedback outside of the user survey","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-20T22:41:28Z","receivedAt":"2008-10-20T22:41:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Jaeger <christian@jaeger.mine.nu> writes:\n\n>> That's partially implemented, I think (google for Nguy (or something, I'm\n>> not very god with asian names),\n>\n> That's not enough information for me to find what you've had in\n> mind. \"stump Nguy site:marc.info\" doesn't yield a result with Google.\n\nI think Andreas is referring to nd/narrow topic currently parked in 'pu'.\n\n$ git log next..36aa66d^2\n"},{"id":"93581","messageId":"48FD839C.1070604@jaeger.mine.nu","threadId":"15925","inReplyTo":"7viqrm3n53.fsf@gitster.siamese.dyndns.org","subject":"Re: Feedback outside of the user survey","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-10-21T07:24:12Z","receivedAt":"2008-10-21T07:24:12Z","isPatch":false,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Junio C Hamano wrote:\n> Christian Jaeger <christian@jaeger.mine.nu> writes:\n>\n>   \n>>> That's partially implemented, I think (google for Nguy (or something, I'm\n>>> not very god with asian names),\n>>>       \n>> That's not enough information for me to find what you've had in\n>> mind. \"stump Nguy site:marc.info\" doesn't yield a result with Google.\n>>     \n>\n> I think Andreas is referring to nd/narrow topic currently parked in 'pu'.\n>\n> $ git log next..36aa66d^2\n\nThanks. This looks nice.\n\n(It is implementing the partial, or \"sparse\" as Nguyễn calls it, \ncheckouts. So it seems the more useful of the two ideas is basically \nalready done, at least in the sense of saving space for the checkout. It \nwon't 'move'/'mount' the subdirectory to the top of the working \ndirectory if only a subdirectory is wanted, but as I've already realized \nand written, Git may require a full working directory anyway for \ninteraction with the user during merging, and a symlink can be used \ninstead to 'mount' the subdirectory where the user wants it (if the OS \nsupports that). Straightforward solution.)\n\nChristian.\n"}]}