{"thread":{"id":"6176","subject":"RFC: working with sparse work-copy: where to start?","startedAt":"2006-12-31T10:42:17Z","lastAt":"2007-01-01T09:24:13Z","messageCount":3,"participants":["Michael S. Tsirkin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30573","messageId":"20061231104217.GE26552@mellanox.co.il","threadId":"6176","inReplyTo":null,"subject":"RFC: working with sparse work-copy: where to start?","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2006-12-31T10:42:17Z","receivedAt":"2006-12-31T10:42:17Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Hi!\nI've been thinking about working in a sparsely-populated work copy.\nE.g. svn will let you do a checkout of a specific sub-directory\nand do all your development there assuming you only care about\nchanges in that directory. Ideally, it would be possible to specify\na set of directories that I care about.\n\ngit does close to what I want if I do git-clone -n and then\ngit-checkout <subdirectory>.\n\nHowever,\n1. This re-creates the same directory structure that the repository has.\n   Especially for when this directory resides deep in the original repo\n   tree structure, it would be nice to be able relocate the directory anywhere.\n2. The rest of the tree is checked-out whenever I pull from the central repo.\n3. git-commit would list all files I didn't check out as removed.\n\nI wonder how hard would it be to add such support?\nI tried looking at 2 - is builtin-merge-file.c the only place where the checkout\nis done on merge?\n\nWhat other commands need to be fixed for this to work?\n\n-- \nMST\n"},{"id":"30589","messageId":"7vodpjdekh.fsf@assigned-by-dhcp.cox.net","threadId":"6176","inReplyTo":"20061231104217.GE26552@mellanox.co.il","subject":"Re: RFC: working with sparse work-copy: where to start?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-31T19:56:46Z","receivedAt":"2006-12-31T19:56:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@mellanox.co.il> writes:\n\n> Hi!\n> I've been thinking about working in a sparsely-populated work copy.\n> E.g. svn will let you do a checkout of a specific sub-directory\n> and do all your development there assuming you only care about\n> changes in that directory. Ideally, it would be possible to specify\n> a set of directories that I care about.\n> ...\n> What other commands need to be fixed for this to work?\n\nPretty much everything needs to be changed, I suspect.\n\nThe point of git is to track the whole tree, and that is\ningrained to the design of the tool everywhere.  You need to\nbend backwards to operate in the way you propose; I am not\nsaying it is impossible but I suspect it will be very hard or\ninefficient or both.\n\nYour commits, although your working tree will only have selected\nsubtrees in \"wrong\" places, should have the same \"directory\nstructure\" as everybody else.  This is an absolute requirement\nfor the result of your work in your repository to be usable by\nothers.\n\nOne design level thing you need to worry about is what to do\nwith merges, if you are pulling from more than one people and\nthey start their work in different version of \"the whole tree\".\nYou may not be interested in what happens in \"other parts\" of\nthe whole tree you are not checking out.  For your merge result\nto be any useful for other people you later want to merge from\nyou, you still have to come up with and record the sensible\nresult when these \"other parts\" have conflicts.\n\nThis means the tree objects you will create as the final product\nhas to have the same directory structure as other people, while\nyour working tree will have only selected things, and in \"wrong\"\n(from the tree's perspective) places.\n\nOne decision you need to make early is which side you place your\nindex on.\n\nOne approach would be to have the same directory structure in\nthe index.  The other possibility is to match the directory\nstructure recorded in the index with the structure of your\nworking tree.  I am not sure pros-and-cons offhand.\n\nRegardless of which avenue you pursue, you need to have a way to\ntell your version of git which subtree your repository is\ninterested in, and where in your working tree you want to check\nthem out.  And you would need to change affected commands to\ntake this new information into account when do their work.\n\nThe former approach means you do not have to touch write-tree\nand read-tree, but your diff-index, diff-tree (when you want it\nto work sensibly inside subdirectories), checkout-index and\nupdate-index need to know about this.  The latter means you do\nnot have to touch diff-files, update-index and checkout-index,\nbut read-tree will be affected.  Any command that deals with\nboth tree and working directory at the same time (diff-index,\nread-tree -u, merge-recursive, etc.) or works from a\nsubdirectory (pretty much all Porcelain commands -- think of\n'git add .' in a subdirectory) will need to change regardless of\nwhich approach is taken.\n\nI think it would be a lot simpler if you do not mind deep\ndirectory structure but still support a sparse checkout,\nthough.\n"},{"id":"30616","messageId":"20070101092413.GB9114@mellanox.co.il","threadId":"6176","inReplyTo":"7vodpjdekh.fsf@assigned-by-dhcp.cox.net","subject":"Re: RFC: working with sparse work-copy: where to start?","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-01-01T09:24:13Z","receivedAt":"2007-01-01T09:24:13Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> > Hi!\n> > I've been thinking about working in a sparsely-populated work copy.\n> > E.g. svn will let you do a checkout of a specific sub-directory\n> > and do all your development there assuming you only care about\n> > changes in that directory. Ideally, it would be possible to specify\n> > a set of directories that I care about.\n> > ...\n> > What other commands need to be fixed for this to work?\n> \n> Pretty much everything needs to be changed, I suspect.\n> \n> The point of git is to track the whole tree, and that is\n> ingrained to the design of the tool everywhere.  You need to\n> bend backwards to operate in the way you propose; I am not\n> saying it is impossible but I suspect it will be very hard or\n> inefficient or both.\n> \n> Your commits, although your working tree will only have selected\n> subtrees in \"wrong\" places, should have the same \"directory\n> structure\" as everybody else.  This is an absolute requirement\n> for the result of your work in your repository to be usable by\n> others.\n> \n> One design level thing you need to worry about is what to do\n> with merges, if you are pulling from more than one people and\n> they start their work in different version of \"the whole tree\".\n> You may not be interested in what happens in \"other parts\" of\n> the whole tree you are not checking out.  For your merge result\n> to be any useful for other people you later want to merge from\n> you, you still have to come up with and record the sensible\n> result when these \"other parts\" have conflicts.\n\nYes, I've been thinking about this problem. As far as the merge can be\ndone in-index it should be fine though. Maybe failing a merge if there are\nmerges that can't be done with the checked out subtree is the right thing to do.\nBut, this means that we should try harder to merge in-index\nchanges that touch non-checked-out files.\n\nFor example, a commit could touch a checked-out and non-checked out file,\nand non-checked-out file could be index-mergeable but checked-out one\nwould need file level merge. Yes?\n\n> This means the tree objects you will create as the final product\n> has to have the same directory structure as other people, while\n> your working tree will have only selected things, and in \"wrong\"\n> (from the tree's perspective) places.\n> \n> One decision you need to make early is which side you place your\n> index on.\n> \n> One approach would be to have the same directory structure in\n> the index.  The other possibility is to match the directory\n> structure recorded in the index with the structure of your\n> working tree.  I am not sure pros-and-cons offhand.\n> \n> Regardless of which avenue you pursue, you need to have a way to\n> tell your version of git which subtree your repository is\n> interested in, and where in your working tree you want to check\n> them out.  And you would need to change affected commands to\n> take this new information into account when do their work.\n> \n> The former approach means you do not have to touch write-tree\n> and read-tree, but your diff-index, diff-tree (when you want it\n> to work sensibly inside subdirectories), checkout-index and\n> update-index need to know about this.  The latter means you do\n> not have to touch diff-files, update-index and checkout-index,\n> but read-tree will be affected.  Any command that deals with\n> both tree and working directory at the same time (diff-index,\n> read-tree -u, merge-recursive, etc.) or works from a\n> subdirectory (pretty much all Porcelain commands -- think of\n> 'git add .' in a subdirectory) will need to change regardless of\n> which approach is taken.\n> \n> I think it would be a lot simpler if you do not mind deep\n> directory structure but still support a sparse checkout,\n> though.\n\nOK, I don't mind the deep directory structure so much.\n\nI'm sorry, Junio, but I'm a bit lost wrt which of your comments\nare related to the directory structure change idea\n(which it seems wise to drop) and which to the sparse checkout\nsupport which might be more doable. Could you help please?\n\n-- \nMST\n"}]}