{"thread":{"id":"29293","subject":"git-subtree","startedAt":"2012-01-04T15:53:36Z","lastAt":"2012-01-30T16:56:53Z","messageCount":15,"participants":["David Greene","Ramkumar Ramachandra","David A. Greene","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"181921","messageId":"nngaa638nwf.fsf@transit.us.cray.com","threadId":"29293","inReplyTo":null,"subject":"git-subtree","fromName":"David Greene","fromEmail":"dag@cray.com","sentAt":"2012-01-04T15:53:36Z","receivedAt":"2012-01-04T15:53:36Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Hey all,\n\nAvery Pennarun has suckered me into^W^W^Wasked me to submit his\ngit-subtree tool for inclusion into mainline. Apparently there was some\ndiscussion about this at GitTogether.\n\nI have a patch ready. It takes git-subtree from the current GitHub\nmaster, fixes the tests to use the standard git test harness and updates\nthe build to recognize git-subtree.\n\nHow does the git community want the patch presented? Right now it's one\nmonolithic thing. I understand that isn't ideal but I don't think\nincorporating the entire GitHub master history is necessarily the best\nidea either.\n\nSo I'm looking for some guidance.\n\nThanks!\n\n -Dave\n"},{"id":"181969","messageId":"CALkWK0nU9iO_6CCbWw8c_Fz=xodkaAW4300Jpc7M7D+kBP=QRg@mail.gmail.com","threadId":"29293","inReplyTo":"nngaa638nwf.fsf@transit.us.cray.com","subject":"Re: git-subtree","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2012-01-05T11:28:22Z","receivedAt":"2012-01-05T11:28:22Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi David,\n\nDavid Greene wrote:\n> I have a patch ready.\n> How does the git community want the patch presented?\n\nPlease read and follow the guidelines listed in\nDocumentation/SubmittingPatches. The TL;DR version is: break it up\ninto logical reviewable commits based on the current `master` and use\ngit format-patch/ git send-email to send those commits to this mailing\nlist.\n\nCheers!\n\n-- Ram\n\n[1]: https://raw.github.com/git/git/master/Documentation/SubmittingPatches\n"},{"id":"181977","messageId":"87ipkq199w.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"CALkWK0nU9iO_6CCbWw8c_Fz=xodkaAW4300Jpc7M7D+kBP=QRg@mail.gmail.com","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T15:03:38Z","receivedAt":"2012-01-05T15:03:38Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Hi David,\n>\n> David Greene wrote:\n>> I have a patch ready.\n>> How does the git community want the patch presented?\n>\n> Please read and follow the guidelines listed in\n> Documentation/SubmittingPatches. The TL;DR version is: break it up\n> into logical reviewable commits based on the current `master` and use\n> git format-patch/ git send-email to send those commits to this mailing\n> list.\n\nI've read that document. The issue is that I didn't develop the code,\nAvery did. This is a completely new tool for git and I don't have the\nfirst idea of what \"logical\" chunks would look like. I assume, for\nexample, that we'd want the first \"chunk\" to actually work and do\nsomething interesting. I can go spend a bunch of time to see if I can\ngrok enough to create these chunks but I wanted to check first and make\nsure that would be absolutely necessary. It's a lot of time to learn a\ncompletely new codebase. I was hoping to submit something soon and then\nlearn the codebase gradually during maintenance/further development.\n\nHow have completely new tools be introduced into the git mainline in the\npast?\n\nThanks!\n\n -Dave\n"},{"id":"181979","messageId":"CALkWK0k+AwCsizZFwbKKxuz0B4xLoyC4hAy3WRD=sLCq-HvvCw@mail.gmail.com","threadId":"29293","inReplyTo":"87ipkq199w.fsf@smith.obbligato.org","subject":"Re: git-subtree","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2012-01-05T15:32:16Z","receivedAt":"2012-01-05T15:32:16Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi again,\n\n[+CC: Junio Hamano, our maintainer]\n\nDavid A. Greene wrote:\n> I've read that document.  The issue is that I didn't develop the code,\n> Avery did.\n\nNot an issue as long as you have Avery's signoff.\n\n> It's a lot of time to learn a\n> completely new codebase.  I was hoping to submit something soon and then\n> learn the codebase gradually during maintenance/further development.\n\nWe certainly don't want badly reviewed code that nobody understands\nfloating around in the codebase- so, I'd suggest sending out whatever\nyou think is appropriate for the first round of reviews, and see how\nthings shape up from there.\n\n> How have completely new tools be introduced into the git mainline in the\n> past?\n\nYes. For an example of something I was involved with but didn't\nauthor, see vcs-svn/.\n\n-- Ram\n"},{"id":"181981","messageId":"20120105154740.GA11475@sigill.intra.peff.net","threadId":"29293","inReplyTo":"87ipkq199w.fsf@smith.obbligato.org","subject":"Re: git-subtree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-05T15:47:40Z","receivedAt":"2012-01-05T15:47:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 05, 2012 at 09:03:38AM -0600, David A. Greene wrote:\n\n> > Please read and follow the guidelines listed in\n> > Documentation/SubmittingPatches. The TL;DR version is: break it up\n> > into logical reviewable commits based on the current `master` and use\n> > git format-patch/ git send-email to send those commits to this mailing\n> > list.\n> \n> I've read that document. The issue is that I didn't develop the code,\n> Avery did. This is a completely new tool for git and I don't have the\n> first idea of what \"logical\" chunks would look like. I assume, for\n> example, that we'd want the first \"chunk\" to actually work and do\n> something interesting. I can go spend a bunch of time to see if I can\n> grok enough to create these chunks but I wanted to check first and make\n> sure that would be absolutely necessary. It's a lot of time to learn a\n> completely new codebase. I was hoping to submit something soon and then\n> learn the codebase gradually during maintenance/further development.\n\nI think this is also somewhat different in that git-subtree has a\nmulti-year history in git that we may want to keep. So it is more\nanalogous to something like gitweb or git-gui, which we have brought in\n(using subtree merges, no less).\n\nThe biggest decision is whether or not to import the existing history.\nIf we do, then we have to decide whether it becomes a sub-component like\ngitweb (e.g., it gets pulled into a \"subtree\" directory, and we have\nmake recurse into it), or whether it gets overlaid into the main\ndirectory (i.e., we clean and munge the subtree repo a bit, then just\n\"git merge\" the history in).\n\nIf we want to throw away the existing history, then I think you end up\ndoing the same munging as the latter option above, and then just make a\nsingle patch out of it instead of a merge.\n\nI don't use git-subtree, but just glancing over the repo, it looks like\nthat munging is mostly:\n\n 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile\n\n 2. the test.sh script gets adapted into t/tXXXX-subtree.sh\n\n 3. git-subtree.txt goes into Documentation/\n\n 4. The rest of the files are infrastructure that can go away, as they\n are a subset of what git.git already contains.\n\nI'd favor keeping the history and doing the munge-overlay thing.\nAlthough part of me wants to join the histories in a subtree so that we\ncan use \"git subtree\" to do it (which would just be cool), I think the\nresulting code layout doesn't make much sense unless git-subtree is\ngoing to be maintained separately.\n\n-Peff\n"},{"id":"181982","messageId":"7vboqino1r.fsf@alter.siamese.dyndns.org","threadId":"29293","inReplyTo":"nngaa638nwf.fsf@transit.us.cray.com","subject":"Re: git-subtree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-05T15:53:36Z","receivedAt":"2012-01-05T15:53:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Greene writes:\n\n> How does the git community want the patch presented? Right now it's one\n> monolithic thing. I understand that isn't ideal but I don't think\n> incorporating the entire GitHub master history is necessarily the best\n> idea either.\n\nIt depends on the longer term vision of how the result of this submission\nwill evolve and more importantly, where you fit in the piture.\n\nOne possible answer you could give us might go like this:\n\n The longer term vision is for \"git subtree\" to become, and be\n developed further as, an integral part of the core git suite.\n\n I have been an active contributor to the \"git subtree\" project for\n quite some time, and am very familiar with the code. Avery has been\n too busy to properly take care of the maintenance of \"git subtree\",\n and expected to be so for the foreseeable future. I will address any\n issue raised during the initial review and will be taking over its\n maintenance and further development.\n\n My plan is to put this first to contrib/ area, keep it there for a few\n release cycles while ironing out remaining kinks in the code, and\n eventually make it one of the \"git\" subcommands. Avery's external tree\n will cease to exist as future development will happen in-tree in the\n git repository.\n\nYour answer might differ, of course, but the point is that we would need\nto weigh pros and cons between inclusion of it in the git repository and\nkeeping it in Avery's repository and have him and his contributors\nmaintain, enhance and distribute it from there, and it largely depends on\nthe nature of the submission. Is it a \"throw it over the wall\" dump of a\nlarge code of unknown quality that we need to clean up first without\nknowing the vision of how \"git subtree\" should evolve by original author\nand/or people who have been actively developing it?\n"},{"id":"182001","messageId":"87zke2yv27.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"20120105154740.GA11475@sigill.intra.peff.net","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T16:26:40Z","receivedAt":"2012-01-05T16:26:40Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Jeff King writes:\n\n> I think this is also somewhat different in that git-subtree has a\n> multi-year history in git that we may want to keep. So it is more\n\nI agree there may be some value in preserving this history.\n\n> The biggest decision is whether or not to import the existing history.\n\nI agree. I will leave that decision to the more experienced git\ndevelopers. I'm happy to work either way.\n\n> If we want to throw away the existing history, then I think you end up\n> doing the same munging as the latter option above, and then just make a\n> single patch out of it instead of a merge.\n\nRight. That's the approach I've taken for now but it's easy to switch.\nThere aren't that many changes.\n\n> I don't use git-subtree, but just glancing over the repo, it looks like\n> that munging is mostly:\n>\n> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile\n\nDone.\n\n> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh\n\nDone.\n\n> 3. git-subtree.txt goes into Documentation/\n\nDone.\n\n> 4. The rest of the files are infrastructure that can go away, as they\n> are a subset of what git.git already contains.\n\nDone.\n\nI have a patch that does all of the above but it is one monolithic blob.\nLike I said, the changes aren't extensive so it's easy for me to change\nstrategies.\n\n> I'd favor keeping the history and doing the munge-overlay thing.\n\nOk, that sounds fine to me. I'll do that in a private branch. What\nshould I send as patches to the mailing list? I'm assuming we don't\nwant [PATCH 235/12342], etc. sent to the list chronicling the entire\nhistory. :)\n\n> Although part of me wants to join the histories in a subtree so that we\n> can use \"git subtree\" to do it (which would just be cool),\n\nHeh. I thought about that too. :)\n\n> I think the resulting code layout doesn't make much sense unless\n> git-subtree is going to be maintained separately.\n\nYeah, I agree.\n\n -Dave\n"},{"id":"181999","messageId":"87sjjuyur3.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"CALkWK0k+AwCsizZFwbKKxuz0B4xLoyC4hAy3WRD=sLCq-HvvCw@mail.gmail.com","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T16:33:20Z","receivedAt":"2012-01-05T16:33:20Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Hi again,\n>\n> [+CC: Junio Hamano, our maintainer]\n>\n> David A. Greene wrote:\n>> I've read that document.  The issue is that I didn't develop the code,\n>> Avery did.\n>\n> Not an issue as long as you have Avery's signoff.\n\nAs in a signed-off-by log entry on the commit? I did a commit -s to add\nmy own signed-off-by tag and added a \"From:\" line in accordance with the\nSubmittingPatches document:\n\n \"If you are forwarding a patch from somebody else, optionally, at the\n beginning of the e-mail message just before the commit message starts,\n you can put a \"From: \" line to name that person.\"\n\nI have not used signoffs before in my day-to-day git flow. How do I go\nabout getting one from Avery and incorporating it into the history in an\nautheticated way? I'm assuming you don't want me to forge his sign-off.\n:)\n\n>> It's a lot of time to learn a\n>> completely new codebase.  I was hoping to submit something soon and then\n>> learn the codebase gradually during maintenance/further development.\n>\n> We certainly don't want badly reviewed code that nobody understands\n> floating around in the codebase- \n\nCertainly, I'm not trying to avoid review, just trying to figure out the\nmost efficient mechanics.\n\n> so, I'd suggest sending out whatever you think is appropriate for the\n> first round of reviews, and see how things shape up from there.\n\nFair enough. I think I will take Jeff's suggested route and see where\nthat goes.\n\n>> How have completely new tools be introduced into the git mainline in the\n>> past?\n>\n> Yes. For an example of something I was involved with but didn't\n> author, see vcs-svn/.\n\nOk, I'll look into that. Thanks for the pointer.\n\n -Dave\n"},{"id":"182000","messageId":"87obuiyu20.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"7vboqino1r.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T16:48:23Z","receivedAt":"2012-01-05T16:48:23Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano writes:\n\n> David Greene writes:\n>\n>> How does the git community want the patch presented? Right now it's one\n>> monolithic thing. I understand that isn't ideal but I don't think\n>> incorporating the entire GitHub master history is necessarily the best\n>> idea either.\n>\n> It depends on the longer term vision of how the result of this submission\n> will evolve and more importantly, where you fit in the piture.\n\nThis is a very fair question. I'll try to answer it as best I can. I\nthink it mostly jibes with your suggested possible answer.\n\nI've been using git-subtree for about six months now and as an\nenthusiastic user who wants to introduce this too into my daily\ncorporate work environment, I'd like to see it incorporated as an\nofficially-supported git tool to make that introduction easier.\n\nSo my intention is to make git-subtree an integral part of the core git\nsuite and take on further maintenance and development along with Avery\nand the other git-subtree developers.\n\nI have not previously been a contributor to git-subtree and don't know\nthe code at all but I am a quick learner. The actual git-subtree code\nitself is not overwhelmingly large and strikes me as a tractable\nlearning project.\n\nI approached Avery about submitting git-subtree to become part of the\ncore git suite. He responded positively but indicated he does not have\nthe cycles to do it at this time. He asked whether I could take on the\njob and I agreed.\n\nHe mentioned that he'd talked to some developers at GitTogether and got\na positive reponse there. I don't know whether you were part of those\ndiscussions. My impression is that the GitTogether discussions went\nwell and there was general agreement that git-subtree would be a\nvaluable addition to the core git suite.\n\nI am perfectly happy to put this in contrib/ first if it eases the\nintroduction. I would like to move it to the subcommand area after\ngetting everything in tip-top shape. What I don't want is for it to\nlanguish forever in contrib/. That means I'll need some guideline of\nthe changes/standards necessary to qualify it for transition from\ncontrib/ to an official subcommand. I expect we'll develop that as we\ngo along but I hope the git community has some institutional knowledge\ngathered from previous experience.\n\nI have asked Avery how he wants to do maintenance going forward. I\nhaven't heard back from him yet so I can't speak to whether the existing\nGitHub project will continue or not. I'll pass along his thoughts when\nI get them.\n\n> Your answer might differ, of course, but the point is that we would need\n> to weigh pros and cons between inclusion of it in the git repository and\n> keeping it in Avery's repository and have him and his contributors\n> maintain, enhance and distribute it from there, and it largely depends on\n> the nature of the submission. Is it a \"throw it over the wall\" dump of a\n> large code of unknown quality that we need to clean up first without\n> knowing the vision of how \"git subtree\" should evolve by original author\n> and/or people who have been actively developing it?\n\nI certainly don't want this to be an \"over the wall\" operation. I\nintend to participate in maintenance of git-subtree in the official git\nrepository.\n\nSo I'll go ahead and work on adding this to contrib/. Once I get a\nresponse from Avery about his long-term vision I'll pass that along and\nwe can have further discussion. I may start sending patches to the\nmailing list for review before hearing back from him, however.\n\nSound good?\n\n -Dave\n"},{"id":"182002","messageId":"8762gpyeui.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"20120105154740.GA11475@sigill.intra.peff.net","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T22:16:53Z","receivedAt":"2012-01-05T22:16:53Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Jeff King writes:\n\n> I think this is also somewhat different in that git-subtree has a\n> multi-year history in git that we may want to keep. So it is more\n\nI agree there may be some value in preserving this history.\n\n> The biggest decision is whether or not to import the existing history.\n\nI agree. I will leave that decision to the more experienced git\ndevelopers. I'm happy to work either way.\n\n> If we want to throw away the existing history, then I think you end up\n> doing the same munging as the latter option above, and then just make a\n> single patch out of it instead of a merge.\n\nRight. That's the approach I've taken for now but it's easy to switch.\nThere aren't that many changes.\n\n> I don't use git-subtree, but just glancing over the repo, it looks like\n> that munging is mostly:\n>\n> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile\n\nDone.\n\n> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh\n\nDone.\n\n> 3. git-subtree.txt goes into Documentation/\n\nDone.\n\n> 4. The rest of the files are infrastructure that can go away, as they\n> are a subset of what git.git already contains.\n\nDone.\n\nI have a patch that does all of the above but it is one monolithic blob.\nLike I said, the changes aren't extensive so it's easy for me to change\nstrategies.\n\n> I'd favor keeping the history and doing the munge-overlay thing.\n\nOk, that sounds fine to me. I'll do that in a private branch. What\nshould I send as patches to the mailing list? I'm assuming we don't\nwant [PATCH 235/12342], etc. sent to the list chronicling the entire\nhistory. :)\n\n> Although part of me wants to join the histories in a subtree so that we\n> can use \"git subtree\" to do it (which would just be cool),\n\nHeh. I thought about that too. :)\n\n> I think the resulting code layout doesn't make much sense unless\n> git-subtree is going to be maintained separately.\n\nYeah, I agree.\n\n -Dave\n"},{"id":"181998","messageId":"871urdyesl.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"CALkWK0k+AwCsizZFwbKKxuz0B4xLoyC4hAy3WRD=sLCq-HvvCw@mail.gmail.com","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T22:18:02Z","receivedAt":"2012-01-05T22:18:02Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Hi again,\n>\n> [+CC: Junio Hamano, our maintainer]\n>\n> David A. Greene wrote:\n>> I've read that document. The issue is that I didn't develop the code,\n>> Avery did.\n>\n> Not an issue as long as you have Avery's signoff.\n\nAs in a signed-off-by log entry on the commit? I did a commit -s to add\nmy own signed-off-by tag and added a \"From:\" line in accordance with the\nSubmittingPatches document:\n\n \"If you are forwarding a patch from somebody else, optionally, at the\n beginning of the e-mail message just before the commit message starts,\n you can put a \"From: \" line to name that person.\"\n\nI have not used signoffs before in my day-to-day git flow. How do I go\nabout getting one from Avery and incorporating it into the history in an\nautheticated way? I'm assuming you don't want me to forge his sign-off.\n:)\n\n>> It's a lot of time to learn a completely new codebase. I was hoping\n>> to submit something soon and then learn the codebase gradually during\n>> maintenance/further development.\n>\n> We certainly don't want badly reviewed code that nobody understands\n> floating around in the codebase\n\nCertainly, I'm not trying to avoid review, just trying to figure out the\nmost efficient mechanics.\n\n> so, I'd suggest sending out whatever you think is appropriate for the\n> first round of reviews, and see how things shape up from there.\n\nFair enough. I think I will take Jeff's suggested route and see where\nthat goes.\n\n>> How have completely new tools be introduced into the git mainline in the\n>> past?\n>\n> Yes. For an example of something I was involved with but didn't\n> author, see vcs-svn/.\n\nOk, I'll look into that. Thanks for the pointer.\n\n -Dave\n"},{"id":"181997","messageId":"87wr95x06e.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"7vboqino1r.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-05T22:19:05Z","receivedAt":"2012-01-05T22:19:05Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano writes:\n\n> David Greene writes:\n>\n>> How does the git community want the patch presented? Right now it's one\n>> monolithic thing. I understand that isn't ideal but I don't think\n>> incorporating the entire GitHub master history is necessarily the best\n>> idea either.\n>\n> It depends on the longer term vision of how the result of this submission\n> will evolve and more importantly, where you fit in the piture.\n\nThis is a very fair question. I'll try to answer it as best I can. I\nthink it mostly jibes with your suggested possible answer.\n\nI've been using git-subtree for about six months now and as an\nenthusiastic user who wants to introduce this too into my daily\ncorporate work environment, I'd like to see it incorporated as an\nofficially-supported git tool to make that introduction easier.\n\nSo my intention is to make git-subtree an integral part of the core git\nsuite and take on further maintenance and development along with Avery\nand the other git-subtree developers.\n\nI have not previously been a contributor to git-subtree and don't know\nthe code at all but I am a quick learner. The actual git-subtree code\nitself is not overwhelmingly large and strikes me as a tractable\nlearning project.\n\nI approached Avery about submitting git-subtree to become part of the\ncore git suite. He responded positively but indicated he does not have\nthe cycles to do it at this time. He asked whether I could take on the\njob and I agreed.\n\nHe mentioned that he'd talked to some developers at GitTogether and got\na positive reponse there. I don't know whether you were part of those\ndiscussions. My impression is that the GitTogether discussions went\nwell and there was general agreement that git-subtree would be a\nvaluable addition to the core git suite.\n\nI am perfectly happy to put this in contrib/ first if it eases the\nintroduction. I would like to move it to the subcommand area after\ngetting everything in tip-top shape. What I don't want is for it to\nlanguish forever in contrib/. That means I'll need some guideline of\nthe changes/standards necessary to qualify it for transition from\ncontrib/ to an official subcommand. I expect we'll develop that as we\ngo along but I hope the git community has some institutional knowledge\ngathered from previous experience.\n\nI have asked Avery how he wants to do maintenance going forward. I\nhaven't heard back from him yet so I can't speak to whether the existing\nGitHub project will continue or not. I'll pass along his thoughts when\nI get them.\n\n> Your answer might differ, of course, but the point is that we would need\n> to weigh pros and cons between inclusion of it in the git repository and\n> keeping it in Avery's repository and have him and his contributors\n> maintain, enhance and distribute it from there, and it largely depends on\n> the nature of the submission. Is it a \"throw it over the wall\" dump of a\n> large code of unknown quality that we need to clean up first without\n> knowing the vision of how \"git subtree\" should evolve by original author\n> and/or people who have been actively developing it?\n\nI certainly don't want this to be an \"over the wall\" operation. I\nintend to participate in maintenance of git-subtree in the official git\nrepository.\n\nSo I'll go ahead and work on adding this to contrib/. Once I get a\nresponse from Avery about his long-term vision I'll pass that along and\nwe can have further discussion. I may start sending patches to the\nmailing list for review before hearing back from him, however.\n\nSound good?\n\n -Dave\n"},{"id":"182005","messageId":"8739btwq8l.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"87sjjuyur3.fsf@smith.obbligato.org","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-06T01:53:46Z","receivedAt":"2012-01-06T01:53:46Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> Ramkumar Ramachandra writes:\n>\n>> Hi again,\n>>\n>> [+CC: Junio Hamano, our maintainer]\n>>\n>> David A. Greene wrote:\n>>> I've read that document.  The issue is that I didn't develop the code,\n>>> Avery did.\n>>\n>> Not an issue as long as you have Avery's signoff.\n\nArgh. Sorry about all the duplicate replies. I got delivery bounces on\nall of them. Must have been a stuck queue or something. So again,\napologies for the noise.\n\n -Dave\n"},{"id":"183287","messageId":"87aa56kvr4.fsf@smith.obbligato.org","threadId":"29293","inReplyTo":"87zke2yv27.fsf@smith.obbligato.org","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-01-29T22:07:59Z","receivedAt":"2012-01-29T22:07:59Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n>> I'd favor keeping the history and doing the munge-overlay thing.\n>\n> Ok, that sounds fine to me. I'll do that in a private branch. What\n> should I send as patches to the mailing list? I'm assuming we don't\n> want [PATCH 235/12342], etc. sent to the list chronicling the entire\n> history. :)\n>\n>> Although part of me wants to join the histories in a subtree so that we\n>> can use \"git subtree\" to do it (which would just be cool),\n>\n> Heh. I thought about that too. :)\n\nI actually did end up doing a subtree merge via git subtree. It was\nmore convenient to put it in contrib/ like that as almost everthing\nthere is in its own subdirectory.\n\nI'm cleaning things up there to remove redundancy, rewrite tests (using\nearlier work), etc. What number should I use for git-subtree tests?\nHere are some logical candidates:\n\n 5 - the pull and exporting commands\n 6 - the revision tree commands (even e.g. merge-base)\n 7 - the porcelainish commands concerning the working tree\n 9 - the git tools\n\ngit-subtree can pull and export. It also affects revision trees (it\nmerges, for example) and is a porcelainish command that affects the\nworking tree. It is also a \"git tool\" of a sort.\n\nI originally put them under t97XX but now that is taken, as is\neverything up to and including t99XX.\n\nAnyone have a strong opinion?\n\nThanks!\n\n -Dave\n"},{"id":"183337","messageId":"nngfwexxh62.fsf@transit.us.cray.com","threadId":"29293","inReplyTo":"87aa56kvr4.fsf@smith.obbligato.org","subject":"Re: git-subtree","fromName":"David A. Greene","fromEmail":"dag@cray.com","sentAt":"2012-01-30T16:56:53Z","receivedAt":"2012-01-30T16:56:53Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> I originally put them under t97XX but now that is taken, as is\n> everything up to and including t99XX.\n\nOops, I lied. I originally put them under t79XX and I've kept that for\nnow. Sound good?\n\n -Dave\n"}]}