{"thread":{"id":"29603","subject":"git-subtree Ready #2","startedAt":"2012-02-11T17:35:41Z","lastAt":"2012-03-02T03:42:37Z","messageCount":28,"participants":["David A. Greene","Junio C Hamano","Jeff King","Thomas Rast","Avery Pennarun","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184462","messageId":"877gztmfwy.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":null,"subject":"git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-11T17:35:41Z","receivedAt":"2012-02-11T17:35:41Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"[This bounced for some reason.]\n\nOk, I have http access now:\n\ngit clone http://sources.obbligato.org/git/git.git\ngit pull origin subtree\n\nI might need to fiddle with permissions, let me know.\n\n                              -Dave\n"},{"id":"184464","messageId":"7v8vk9mem4.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"877gztmfwy.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-11T18:03:47Z","receivedAt":"2012-02-11T18:03:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> I might need to fiddle with permissions, let me know.\n\nEverybody's client can talk smart http these days. Please don't\nhost/publish the code behind a dumb HTTP server.\n"},{"id":"184472","messageId":"87mx8pkwfa.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"7v8vk9mem4.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-11T19:22:01Z","receivedAt":"2012-02-11T19:22:01Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> greened@obbligato.org (David A. Greene) writes:\n>\n>> I might need to fiddle with permissions, let me know.\n>\n> Everybody's client can talk smart http these days. Please don't\n> host/publish the code behind a dumb HTTP server.\n\nI'll have to learn how to set up a smart http.\n\nIn the meantime, this should also work:\n\ngit clone git://sources.obbligato.org/git/git.git\n\nOr via gitweb:\n\nhttp://sources.obbligato.org\n\n                               -Dave\n"},{"id":"184744","messageId":"8739acra5j.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"877gztmfwy.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-15T04:30:16Z","receivedAt":"2012-02-15T04:30:16Z","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> [This bounced for some reason.]\n>\n> Ok, I have http access now:\n>\n> git clone http://sources.obbligato.org/git/git.git\n> git pull origin subtree\n\nHaven't heard anything lately so I want to make sure there's not an\naccess problem.\n\nThis is also available at:\n\ngit clone git://sources.obbligato.org/git/git.git\n\nor by gitweb:\n\nhttp://sources.obbligato.org\n\n                          -Dave\n"},{"id":"184746","messageId":"20120215050855.GB29902@sigill.intra.peff.net","threadId":"29603","inReplyTo":"8739acra5j.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-15T05:08:55Z","receivedAt":"2012-02-15T05:08:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 14, 2012 at 10:30:16PM -0600, David A. Greene wrote:\n\n> This is also available at:\n> \n> git clone git://sources.obbligato.org/git/git.git\n\nHmm. So it seems like a pretty straightforward subtree merge of\ngit-subtree. I can't say I'm super excited about having copied bits like\ncontrib/subtree/t/Makefile that are basically replicas of git's\nt/Makefile.  But there's not that much of it, the cruft lives in\ncontrib, and there's really not a good solution short of actually making\ngit-subtree a first-class git command.\n\nBut more important than the physical layout is the maintenance plan\ngoing forward.  Is Avery going to keep maintaining git-subtree, and we\nwill just occasionally pull? Are you maintaining it? Where will patches\ngo? To a github repo? To git@vger?\n\n-Peff\n"},{"id":"184747","messageId":"87sjicpsr1.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"20120215050855.GB29902@sigill.intra.peff.net","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-15T05:31:30Z","receivedAt":"2012-02-15T05:31:30Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Feb 14, 2012 at 10:30:16PM -0600, David A. Greene wrote:\n>\n>> This is also available at:\n>> \n>> git clone git://sources.obbligato.org/git/git.git\n>\n> Hmm. So it seems like a pretty straightforward subtree merge of\n> git-subtree. \n\nYep.\n\n> I can't say I'm super excited about having copied bits like\n> contrib/subtree/t/Makefile that are basically replicas of git's\n> t/Makefile.  \n\nI know, I didn't like it either but could not think of a better way.\n\n> But there's not that much of it, the cruft lives in contrib, and\n> there's really not a good solution short of actually making\n> git-subtree a first-class git command.\n\nThat's the conclusion I came to.  Moving it to a first-class command\nshould be pretty simple when the time comes.\n\n> But more important than the physical layout is the maintenance plan\n> going forward.  Is Avery going to keep maintaining git-subtree, and we\n> will just occasionally pull? Are you maintaining it? Where will patches\n> go? To a github repo? To git@vger?\n\nI am still waiting to hear from Avery on that.  I will ping him again.\nMy intention is to certainly participate in maintenance.  I use\ngit-subtree daily so it's in my interest to keep it working.\n\nI plan to send patcher to git@vger.  I don't think a pull would be\npractical given the removal of redundant files and other things.\n\n                           -Dave\n"},{"id":"184804","messageId":"87ty2ro1zf.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"87sjicpsr1.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-16T04:07:16Z","receivedAt":"2012-02-16T04:07:16Z","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>> But more important than the physical layout is the maintenance plan\n>> going forward.  Is Avery going to keep maintaining git-subtree, and we\n>> will just occasionally pull? Are you maintaining it? Where will patches\n>> go? To a github repo? To git@vger?\n>\n> I am still waiting to hear from Avery on that.  I will ping him again.\n> My intention is to certainly participate in maintenance.  I use\n> git-subtree daily so it's in my interest to keep it working.\n\nI've attached Avery's response below.  The short summary is that he\nthinks maintaining it in the vger git repository is the way to go and\nthat he's fine moving patches to/from GitHub as necessary.\n\nSo again, I will certainly be part of the maintenance team.  There are a\nfew other people currently helping out with maintenance and I will help\nAvery to get the word out about the switch as he requires.\n\n                            -Dave\n\n--8<-----------------------------------------------------------------------\n\nThanks for putting work into this.  You can feel free to cc: me on any\ngit-list discussions if you want.\n\nI haven't done any significant amount of git-subtree maintenance lately,\nbut even if I did, since it's only one file it should be easy to put\nmove patches between github and git whenever we want.  I would suggest\nthat just maintaining it as part of git is the best way to go, since\nhaving diverging versions doesn't really help anyone.\n\nI'm sure the potential benefit of putting git-subtree in the contrib/\ndirectory is that we could then use git-subtree to maintain the\ngit-subtree git subtree, which is a fun wordplay, but perhaps\nironically, as a single rarely-changing file, git-subtree is probably\nnot the right tool for these purposes :)\n\nHave fun,\n\nAvery\n"},{"id":"185010","messageId":"87pqd9wb6m.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"87ty2ro1zf.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-20T19:34:57Z","receivedAt":"2012-02-20T19:34:57Z","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> greened@obbligato.org (David A. Greene) writes:\n>\n>>> But more important than the physical layout is the maintenance plan\n>>> going forward.  Is Avery going to keep maintaining git-subtree, and we\n>>> will just occasionally pull? Are you maintaining it? Where will patches\n>>> go? To a github repo? To git@vger?\n>\n> I've attached Avery's response below.  The short summary is that he\n> thinks maintaining it in the vger git repository is the way to go and\n> that he's fine moving patches to/from GitHub as necessary.\n\nSo what's the next step?  I guess one of the git maintaners will have to\ndo a pull and merge.  Anything I need to do on this end for that to\nhappen?\n\nThanks!\n\n                             -Dave\n"},{"id":"185024","messageId":"20120220205346.GA6335@sigill.intra.peff.net","threadId":"29603","inReplyTo":"87ty2ro1zf.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-20T20:53:46Z","receivedAt":"2012-02-20T20:53:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 15, 2012 at 10:07:16PM -0600, David A. Greene wrote:\n\n> I've attached Avery's response below.  The short summary is that he\n> thinks maintaining it in the vger git repository is the way to go and\n> that he's fine moving patches to/from GitHub as necessary.\n>\n> [From Avery:]\n>> I'm sure the potential benefit of putting git-subtree in the contrib/\n>> directory is that we could then use git-subtree to maintain the\n>> git-subtree git subtree, which is a fun wordplay, but perhaps\n>> ironically, as a single rarely-changing file, git-subtree is probably\n>> not the right tool for these purposes :)\n\nI'm not a git-subtree user, nor am I the maintainer who would pull from\nyou. So I am somewhat on the sidelines of this particular discussion.\n\nUsually we would incubate new and radically different commands in\ncontrib, and then if they prove to be good, make first-class commands of\nthem (e.g., git-new-workdir has been in contrib for a while, and as it\nhas proven itself to many people, there is talk of including it as a\ncore command).\n\nMy impression is that git-subtree has already done this incubation and\nproving step in its own repository (but like I said, I do not use it\nmyself, so that is just going on list hearsay). So it seems like the\nlogical step would be to graduate into the main git repository.  And I\ngather from Avery's response that he agrees.\n\nOf course there's no real reason we can't take it slow by putting it in\ncontrib, and then graduating from there. It just seems like an\nunnecessary and complicated interim step. Either way, I do think it's\nworth saving the commit history by doing a real merge.\n\nI dunno. It is really up to Junio, I guess. He usually relies on list\nconsensus for decisions like this, and there has not been that much\ndiscussion. What do users of git-subtree think, as this would primarily\nbenefit them? And what do other members of the git@vger community who do\nnot use git-subtree think of the burden of carrying it as a first-class\ncommand (not so much the burden of adding it, but of maintaining it,\nfielding reports when it is broken, etc)?\n\nAs a non-user, I am totally fine with it. I think the burden is not that\nhigh, and you have already promised to deal with ongoing maintenance\nissues.\n\n-Peff\n"},{"id":"185044","messageId":"7vd399jdwc.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"20120220205346.GA6335@sigill.intra.peff.net","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-20T23:14:43Z","receivedAt":"2012-02-20T23:14:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Feb 15, 2012 at 10:07:16PM -0600, David A. Greene wrote:\n> ...\n> Of course there's no real reason we can't take it slow by putting it in\n> contrib, and then graduating from there. It just seems like an\n> unnecessary and complicated interim step. Either way, I do think it's\n> worth saving the commit history by doing a real merge.\n>\n> I dunno. It is really up to Junio, I guess.\n\nIt sounds like the simplest and cleanest would be to treat it as if its\ncurrent version came as a patch submission, cook it just like any other\ntopic in 'pu' down to 'next' down to eventually 'master', with the usual\nreview cycle of pointing out what is wrong and needs fixing followed by a\nseries of re-rolls.\n\nThe total amount of change does not look too bad, either:\n\n    $ git diff --stat master...origin/subtree\n     contrib/subtree/.gitignore         |    5 +\n     contrib/subtree/COPYING            |  339 +++++++++++++++++\n     contrib/subtree/Makefile           |   45 +++\n     contrib/subtree/README             |    8 +\n     contrib/subtree/git-subtree.sh     |  712 ++++++++++++++++++++++++++++++++++++\n     contrib/subtree/git-subtree.txt    |  366 ++++++++++++++++++\n     contrib/subtree/t/Makefile         |   71 ++++\n     contrib/subtree/t/t7900-subtree.sh |  508 +++++++++++++++++++++++++\n     contrib/subtree/todo               |   50 +++\n     t/test-lib.sh                      |   11 +-\n     10 files changed, 2114 insertions(+), 1 deletion(-)\n\nIt does look like it needs to start its life in contrib/ if we were to put\nthis in git.git. I haven't looked at the script fully, but it has an issue\nfrom its first line, which is marked with \"#!/bin/bash\".  It is unclear if\nit is infested by bash-isms beyond repair (in which case \"#!/bin/bash\" is\nfine), or it was written portably but was marked with \"#!/bin/bash\" just\nby inertia.  A patch that corresponds to the above diffstat immediately\nshows many style issues including trailing eye-sore whitespaces.\n\nIt seems that it is even capable of installing from contrib/subtree, so\nkeeping it in contrib/ while many issues it may have gets fixed would not\nhurt the original goal of giving the script more visibility.\n\nThe change to t/test-lib.sh should be made independent of this topic, I\nwould think.\n\n----------------------------------------------------------------\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex e28d5fd..c877a91 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -55,6 +55,7 @@ unset $(perl -e '\n \t\t.*_TEST\n \t\tPROVE\n \t\tVALGRIND\n+                BUILD_DIR\n \t));\n \tmy @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);\n \tprint join(\"\\n\", @vars);\n@@ -924,7 +925,15 @@ then\n \t# itself.\n \tTEST_DIRECTORY=$(pwd)\n fi\n-GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n+\n+if test -z \"$GIT_BUILD_DIR\"\n+then\n+    echo Here\n+\t# We allow tests to override this, in case they want to run tests\n+\t# outside of t/, e.g. for running tests on the test library\n+\t# itself.\n+        GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n+fi\n \n if test -n \"$valgrind\"\n then\n----------------------------------------------------------------\nThis change deserves its own justification.\n\nAfter looking at the history of subtree branch there, however, I agree\nthat it would not help anybody to have its history in my tree with log\nmessages like these (excerpt from shortlog output):\n\n      update todo\n      Some todo items reported by pmccurdy\n      todo\n      Docs: when pushing to github, the repo path needs to end in .git\n      todo\n      todo^\n      todo\n      todo: idea for a 'git subtree grafts' command\n"},{"id":"185052","messageId":"87ipj0wy51.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"20120220205346.GA6335@sigill.intra.peff.net","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-21T05:31:22Z","receivedAt":"2012-02-21T05:31:22Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Of course there's no real reason we can't take it slow by putting it in\n> contrib, and then graduating from there. It just seems like an\n> unnecessary and complicated interim step. Either way, I do think it's\n> worth saving the commit history by doing a real merge.\n\nI have no problem starting off in contrib.  I was asking more about the\nlogistics of getting there.\n\n> As a non-user, I am totally fine with it. I think the burden is not that\n> high, and you have already promised to deal with ongoing maintenance\n> issues.\n\nIndeed, I'm more than happy to help with maintenance.  I have one or two\nfixes/enhancements on my list, in fact.\n\n                              -Dave\n"},{"id":"185053","messageId":"87ehtowxu7.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"7vd399jdwc.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-21T05:37:52Z","receivedAt":"2012-02-21T05:37:52Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n> It sounds like the simplest and cleanest would be to treat it as if its\n> current version came as a patch submission, cook it just like any other\n> topic in 'pu' down to 'next' down to eventually 'master', with the usual\n> review cycle of pointing out what is wrong and needs fixing followed by a\n> series of re-rolls.\n\nOk, but we will preserve the history via the subtree merge, yes?\n\n> The total amount of change does not look too bad, either:\n\nYes, it's a fairly small tool.\n\n> It does look like it needs to start its life in contrib/ if we were to put\n> this in git.git. \n\nThat sounds good to me.  It should get a good shakedown before graduating.\n\n> I haven't looked at the script fully, but it has an issue from its\n> first line, which is marked with \"#!/bin/bash\".  It is unclear if it\n> is infested by bash-isms beyond repair (in which case \"#!/bin/bash\" is\n> fine), or it was written portably but was marked with \"#!/bin/bash\"\n> just by inertia.  A patch that corresponds to the above diffstat\n> immediately shows many style issues including trailing eye-sore\n> whitespaces.\n\nOk.\n\n> It seems that it is even capable of installing from contrib/subtree, so\n> keeping it in contrib/ while many issues it may have gets fixed would not\n> hurt the original goal of giving the script more visibility.\n\nRight, I intentially designed it that way.\n\n> The change to t/test-lib.sh should be made independent of this topic, I\n> would think.\n\nOk, I'll propose those changes separately.  They are a prerequisite for\na git-subtree that is easily testable while in contrib.\n\n> ----------------------------------------------------------------\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index e28d5fd..c877a91 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -55,6 +55,7 @@ unset $(perl -e '\n>  \t\t.*_TEST\n>  \t\tPROVE\n>  \t\tVALGRIND\n> +                BUILD_DIR\n>  \t));\n>  \tmy @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);\n>  \tprint join(\"\\n\", @vars);\n> @@ -924,7 +925,15 @@ then\n>  \t# itself.\n>  \tTEST_DIRECTORY=$(pwd)\n>  fi\n> -GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n> +\n> +if test -z \"$GIT_BUILD_DIR\"\n> +then\n> +    echo Here\n> +\t# We allow tests to override this, in case they want to run tests\n> +\t# outside of t/, e.g. for running tests on the test library\n> +\t# itself.\n> +        GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n> +fi\n>  \n>  if test -n \"$valgrind\"\n>  then\n> ----------------------------------------------------------------\n> This change deserves its own justification.\n\nI'll put a patch together with a more extensive explanation.  Basically,\ntests run outside of the top-level t/ directory don't work because there\nare all sort of assumptions in test-lib.sh about where they live.  There\nare comments in test-lib.sh indicating that it should support tests in\nother directories but I could not make it work out of the box.\n\n> After looking at the history of subtree branch there, however, I agree\n> that it would not help anybody to have its history in my tree with log\n> messages like these (excerpt from shortlog output):\n>\n>       update todo\n>       Some todo items reported by pmccurdy\n>       todo\n>       Docs: when pushing to github, the repo path needs to end in .git\n>       todo\n>       todo^\n>       todo\n>       todo: idea for a 'git subtree grafts' command\n\nOk, these are Avery's commits.  I don't know that I have enough context\nto improve the logs but I will look throught revisions and try to figure\nthings out.  Avery, could you be of any help here?  It sounds like we\nneed more descriptive log messages.\n\n                               -Dave\n"},{"id":"185054","messageId":"7vwr7gitjl.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"87ehtowxu7.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-21T06:34:22Z","receivedAt":"2012-02-21T06:34:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>> It sounds like the simplest and cleanest would be to treat it as if its\n>> current version came as a patch submission, cook it just like any other\n>> topic in 'pu' down to 'next' down to eventually 'master', with the usual\n>> review cycle of pointing out what is wrong and needs fixing followed by a\n>> series of re-rolls.\n>\n> Ok, but we will preserve the history via the subtree merge, yes?\n\nI'll comment on just this part, but a short answer is \"no, I do not think\nso\".\n\nEven though you left \"Jeff King writes\", you removed everything he said\nthat I was quoting, and in order to understand why the answer is 'no', it\nwould have been better if you kept this part from what he said in your\nreply:\n\n>> ... Either way, I do think it's\n>> worth saving the commit history by doing a real merge.\n\nas that was what I was agreeing to with my \"as if ... a patch submission\".\n\n>> After looking at the history of subtree branch there, however, I agree\n>> that it would not help anybody to have its history in my tree with log\n>> messages like these (excerpt from shortlog output):\n>>\n>>       update todo\n>>       Some todo items reported by pmccurdy\n>>       todo\n>>       Docs: when pushing to github, the repo path needs to end in .git\n>>       todo\n>>       todo^\n>>       todo\n>>       todo: idea for a 'git subtree grafts' command\n>\n> Ok, these are Avery's commits.  I don't know that I have enough context\n> to improve the logs but I will look throught revisions and try to figure\n> things out.  Avery, could you be of any help here?  It sounds like we\n> need more descriptive log messages.\n\nThat was not what I was suggesting.\n\nI was saying that the history up to the current state, littered with these\ncommits that are not \"logical progression\" but merely \"a snapshot of\nthen-current state\" may not be worth preserving, with or without better\nmessages.\n\nRewriting the entire history to make it a logical progression just for the\nsake of history is obviously not worth the effort.\n\nWhich suggests that taking the end result that exists at the tip of your\nsubtree branch as a single code-drop, without pulling its history, lets us\nstart from a reasonably well tested state and would not lose us anything\nof value.  And that was what I was suggesting.  For our history to explain\nwhy/how the code got there better, another approach might be to instead\ntreat your bd7b2cf (Add 'contrib/subtree/' from commit '2793ee6ba...',\n2012-01-29), which is where you took Avery's then-current state, as the\ncode-drop event that adds everything in contrib/subtree/ with a single\npatch submission. I.e. in a git.git repository:\n\n\tgit checkout -b subtree master\n\tgit fetch git://sources.obbligato.org/git/git.git subtree\n        git merge --squash bd7b2cf\n        git commit -m \"contrib: add git-subtree from Avery's tree\"\n\nto take the tip of your subtree branch.  The history up to that point is\nin Avery's repository where he stopped, which such an approach will not\npull in to git.git.  And then we can replay bd7b2cf..FETCH_HEAD like so:\n\n\tgit checkout FETCH_HEAD\n\tgit rebase --onto subtree bd7b2cf\n\tgit push . HEAD:subtree\n        git checkout pu\n        git merge subtree\n\nto preserve the history since that single code-drop event that records\nyour effort to adjust the code-dump into a better shape to live in our\ncontrib/ area.  That will make it clear the division of blame on the code\nadded to git.git between Avery (everything before the squashed merge) and\nyou (everything after that).\n"},{"id":"185056","messageId":"7vmx8cirvb.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"7vwr7gitjl.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-21T07:10:32Z","receivedAt":"2012-02-21T07:10:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> greened@obbligato.org (David A. Greene) writes:\n>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Jeff King <peff@peff.net> writes:\n>>>\n>>> It sounds like the simplest and cleanest would be to treat it as if its\n>>> current version came as a patch submission, cook it just like any other\n>>> topic in 'pu' down to 'next' down to eventually 'master', with the usual\n>>> review cycle of pointing out what is wrong and needs fixing followed by a\n>>> series of re-rolls.\n>>\n>> Ok, but we will preserve the history via the subtree merge, yes?\n>\n> I'll comment on just this part, but a short answer is \"no, I do not think\n> so\".\n>\n> Even though you left \"Jeff King writes\", you removed everything he said\n> that I was quoting, and in order to understand why the answer is 'no', it\n> would have been better if you kept this part from what he said in your\n> reply:\n>\n>>> ... Either way, I do think it's\n>>> worth saving the commit history by doing a real merge.\n>\n> as that was what I was agreeing to with my \"as if ... a patch submission\".\n\nEhh, s/agree/disagree/;\n"},{"id":"185060","messageId":"7v4nukinio.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"7vwr7gitjl.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-21T08:44:31Z","receivedAt":"2012-02-21T08:44:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> greened@obbligato.org (David A. Greene) writes:\n>\n>> Ok, but we will preserve the history via the subtree merge, yes?\n>\n> I'll comment on just this part, but a short answer is \"no, I do not think\n> so\".\n> ...\n> I was saying that the history up to the current state, littered with these\n> commits that are not \"logical progression\" but merely \"a snapshot of\n> then-current state\" may not be worth preserving, with or without better\n> messages.\n>\n> Rewriting the entire history to make it a logical progression just for the\n> sake of history is obviously not worth the effort.\n\nHaving said all that, my preference is not so strong to out-right veto\ndoing a true merge; I wouldn't lose sleep if we end up merging the tip of\nyour subtree branch with all the history behind it as-is.\n\nBUT.\n\nEven though I freely admit that I was the guilty one who came up with\n\"merge -s subtree\", and Linus's \"gitk merge\" was the original sin, having\na subtree merge like gitk, git-gui and gitweb in the history is not\nwithout downsides.\n\nThe most problematic one that we regularly suffer from is that the\ncommands in the log family cannot work well across a subtree merge with\npathspec limiting, e.g. \"git log git-gui/po\", and we have to resort to\nsomething like:\n\n    $ cd git-gui/po &&\n      git rev-list --parents HEAD . |\n      while read commit parent\n      do\n        git log --pretty=short $parent..$commit^2 -- :/po\n      done | git shortlog -n -e\n\nto achieve what should be a simple \"git shortlog -n -e git-gui/po\".  I\nsuspect that a subtree merge may also lead bisection into uninteresting\ntangents as it joins otherwise disjoint history.\n\nIf we still have an active upstream that grows its history in a separate\nrepository, like gitk and git-gui do, we cannot avoid a subtree merge in\norder to continue merging from them.  Because you seem to be taking over\nand are going to maintain it as part of git.git proper, eventually aiming\nto move it out of contrib/, it's just that I do not think it is worth the\ntrouble.\n"},{"id":"185063","messageId":"87sji4k10f.fsf@thomas.inf.ethz.ch","threadId":"29603","inReplyTo":"87ehtowxu7.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2012-02-21T09:07:44Z","receivedAt":"2012-02-21T09:07:44Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n>> -GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n>> +\n>> +if test -z \"$GIT_BUILD_DIR\"\n>> +then\n>> +    echo Here\n>> +\t# We allow tests to override this, in case they want to run tests\n>> +\t# outside of t/, e.g. for running tests on the test library\n>> +\t# itself.\n>> +        GIT_BUILD_DIR=\"$TEST_DIRECTORY\"/..\n>> +fi\n>\n> I'll put a patch together with a more extensive explanation.  Basically,\n> tests run outside of the top-level t/ directory don't work because there\n> are all sort of assumptions in test-lib.sh about where they live.  There\n> are comments in test-lib.sh indicating that it should support tests in\n> other directories but I could not make it work out of the box.\n\nNote that this will conflict with tr/perftest, which is already in next.\nIt had a similar override, but then made do with the existing\nGIT_TEST_INSTALLED facility.  I think you do need the above here,\nbecause you are not sourcing test-lib from the directory where the test\nlives.  It may then be cleaner to again use GIT_BUILD_DIR in\nt/perf/perf-lib.sh since it does not require knowledge (outside of\ntest-lib) that $GIT_BUILD_DIR/bin-wrappers/ holds the binaries.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"185310","messageId":"CAHqTa-2s1xbAfNvjD7cXBe2TBMs1985nag1NOYVfE+dATvfEWA@mail.gmail.com","threadId":"29603","inReplyTo":"7vd399jdwc.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2012-02-24T01:19:25Z","receivedAt":"2012-02-24T01:19:25Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Feb 20, 2012 at 6:14 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> It sounds like the simplest and cleanest would be to treat it as if its\n> current version came as a patch submission, cook it just like any other\n> topic in 'pu' down to 'next' down to eventually 'master', with the usual\n> review cycle of pointing out what is wrong and needs fixing followed by a\n> series of re-rolls.\n\nYeah, my original intent with git-subtree was to one day submit it as\nbasically a single patch against git.  That's why I have some slightly\nsuspicious commit messages in there (though in my defense, I think\n*most* of the commit messages are quite sensible :)).\n\n> After looking at the history of subtree branch there, however, I agree\n> that it would not help anybody to have its history in my tree with log\n> messages like these (excerpt from shortlog output):\n> [...]\n>      Docs: when pushing to github, the repo path needs to end in .git\n> [...]\n\nThat commit message in particular I thought was perfectly fine; it's\nspecifically a fix to the git-subtree docs to clarify a question from\nan actual user.\n\nOverall I agree that there's little benefit in preserving the history,\nat least as far as I can see, *except* that some code changes were\nsubmitted by people other than me and squashing those changes might\nconceivably cause licensing confusion down the road.  It's probably a\nfairly quick exercise with git-filter-branch to get rid of the more\negregious commit message problems, if that's what we want to do.  (In\nparticular, just expurgating the entire 'todo' file from the history\nprobably makes plenty of sense.)\n\nThere's no value I can see in being able to do future merges from\noutside the tree, so a filter-branch or rebase before merging should\nbe pretty harmless.\n\n> The total amount of change does not look too bad, either:\n>\n>    $ git diff --stat master...origin/subtree\n>     contrib/subtree/.gitignore         |    5 +\n>     contrib/subtree/COPYING            |  339 +++++++++++++++++\n>     contrib/subtree/Makefile           |   45 +++\n>     contrib/subtree/README             |    8 +\n>     contrib/subtree/git-subtree.sh     |  712 ++++++++++++++++++++++++++++++++++++\n>     contrib/subtree/git-subtree.txt    |  366 ++++++++++++++++++\n>     contrib/subtree/t/Makefile         |   71 ++++\n>     contrib/subtree/t/t7900-subtree.sh |  508 +++++++++++++++++++++++++\n>     contrib/subtree/todo               |   50 +++\n>     t/test-lib.sh                      |   11 +-\n>     10 files changed, 2114 insertions(+), 1 deletion(-)\n\nNote that COPYING, .gitignore, Makefile, t/Makefile, todo, and README\nshould probably be ditched if it weren't going into contrib.  The\ninteresting files are git-subtree.{sh,txt} and t7900-subtree.sh.\n\n> I haven't looked at the script fully, but it has an issue\n> from its first line, which is marked with \"#!/bin/bash\".  It is unclear if\n> it is infested by bash-isms beyond repair (in which case \"#!/bin/bash\" is\n> fine), or it was written portably but was marked with \"#!/bin/bash\" just\n> by inertia.\n\nI'm generally pretty careful to avoid bashisms, but since my /bin/sh\nis bash, I usually mark scripts with /bin/bash just to be safe until\nsomeone has actually verified them with a non-bash shell.  I expect\nfew if any problems with that part.\n\n> A patch that corresponds to the above diffstat immediately\n> shows many style issues including trailing eye-sore whitespaces.\n>\n> It seems that it is even capable of installing from contrib/subtree, so\n> keeping it in contrib/ while many issues it may have gets fixed would not\n> hurt the original goal of giving the script more visibility.\n\nPersonally, I would prefer to just iterate the patch a few times to\ncorrect the coding style problems you see, rather than merging into\ncontrib where it might be forgotten rather than fixed.  As Peff\nalluded, people who want to install it separately from git already\ncan; if we're going to merge it into git, let's do it right.\n\nHave fun,\n\nAVery\n"},{"id":"185374","messageId":"7vobsox84l.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"CAHqTa-2s1xbAfNvjD7cXBe2TBMs1985nag1NOYVfE+dATvfEWA@mail.gmail.com","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-24T20:56:58Z","receivedAt":"2012-02-24T20:56:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Avery Pennarun <apenwarr@gmail.com> writes:\n\n> Overall I agree that there's little benefit in preserving the history,\n> at least as far as I can see, *except* that some code changes were\n> submitted by people other than me and squashing those changes might\n> conceivably cause licensing confusion down the road.\n\nThat is a good point, and it sounds like a good enough justification to\nmerge with history, at least for me.\n"},{"id":"185398","messageId":"CAHqTa-1fbi5W7R2fLu3bp7Yuv_ZB9nxhgjHkLGuU8-V4016+JA@mail.gmail.com","threadId":"29603","inReplyTo":"7vobsox84l.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2012-02-24T23:57:33Z","receivedAt":"2012-02-24T23:57:33Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Feb 24, 2012 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Avery Pennarun <apenwarr@gmail.com> writes:\n>> Overall I agree that there's little benefit in preserving the history,\n>> at least as far as I can see, *except* that some code changes were\n>> submitted by people other than me and squashing those changes might\n>> conceivably cause licensing confusion down the road.\n>\n> That is a good point, and it sounds like a good enough justification to\n> merge with history, at least for me.\n\nShould we filter-branch or rebase the history first, or just leave it as is?\n\nLike I said, since I don't expect there to be any more back-and-forth\ndevelopment, rebasing should be pretty harmless.\n\nAvery\n"},{"id":"185402","messageId":"87hayfv75y.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"CAHqTa-1fbi5W7R2fLu3bp7Yuv_ZB9nxhgjHkLGuU8-V4016+JA@mail.gmail.com","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-25T05:00:41Z","receivedAt":"2012-02-25T05:00:41Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Avery Pennarun <apenwarr@gmail.com> writes:\n\n> On Fri, Feb 24, 2012 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Avery Pennarun <apenwarr@gmail.com> writes:\n>>> Overall I agree that there's little benefit in preserving the history,\n>>> at least as far as I can see, *except* that some code changes were\n>>> submitted by people other than me and squashing those changes might\n>>> conceivably cause licensing confusion down the road.\n>>\n>> That is a good point, and it sounds like a good enough justification to\n>> merge with history, at least for me.\n>\n> Should we filter-branch or rebase the history first, or just leave it as is?\n>\n> Like I said, since I don't expect there to be any more back-and-forth\n> development, rebasing should be pretty harmless.\n\nCatching up on e-mail.  :)\n\nI'm happy to do either (rebase or filter-branch).  Just let me know.\nI'm about the send the test-lib.sh patch separately as it's a prereq for\nputting git-subtrees tests in contrib and I think it's generally useful\nanyway.\n\n                           -Dave\n"},{"id":"185406","messageId":"7vy5rrfft2.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"87hayfv75y.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-25T09:00:41Z","receivedAt":"2012-02-25T09:00:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> Avery Pennarun <apenwarr@gmail.com> writes:\n>\n>> Should we filter-branch or rebase the history first, or just leave it as is?\n>>\n>> Like I said, since I don't expect there to be any more back-and-forth\n>> development, rebasing should be pretty harmless.\n>\n> Catching up on e-mail.  :)\n>\n> I'm happy to do either (rebase or filter-branch).  Just let me know.\n\nI would understand Avery's \"should we filter-branch/rebase, or is it OK\nas-is?\", but I do not understand what you mean by \"either rebase or\nfilter-branch is fine\".\n\n> I'm about the send the test-lib.sh patch separately...\n\nThanks, this I understand and should not be a part of git-subtree topic.\n"},{"id":"185430","messageId":"87ty2ft0tm.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"7vy5rrfft2.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-02-25T15:00:37Z","receivedAt":"2012-02-25T15:00:37Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> I'm happy to do either (rebase or filter-branch).  Just let me know.\n>\n> I would understand Avery's \"should we filter-branch/rebase, or is it OK\n> as-is?\", but I do not understand what you mean by \"either rebase or\n> filter-branch is fine\".\n\nSorry, got mixed up there.  I'm not that familiar with filter-branch.\nNow I understand you do both.  :)\n\nSo have we decided to keep the history?\n\n                                 -Dave\n"},{"id":"185562","messageId":"7vobsk56md.fsf@alter.siamese.dyndns.org","threadId":"29603","inReplyTo":"87ty2ft0tm.fsf@smith.obbligato.org","subject":"Re: git-subtree Ready #2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-27T21:06:02Z","receivedAt":"2012-02-27T21:06:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"greened@obbligato.org (David A. Greene) writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>>> I'm happy to do either (rebase or filter-branch).  Just let me know.\n>>\n>> I would understand Avery's \"should we filter-branch/rebase, or is it OK\n>> as-is?\", but I do not understand what you mean by \"either rebase or\n>> filter-branch is fine\".\n>\n> Sorry, got mixed up there.  I'm not that familiar with filter-branch.\n> Now I understand you do both.  :)\n>\n> So have we decided to keep the history?\n\nI think the discussion so far was:\n\n - Peff suggested to keep the history with a true merge;\n\n - I said the history before the final commit in Avery's tree did not look\n   so useful for future archaeology; and then\n\n - Avery corrected me that there are contributions by other people and the\n   credits will be lost if we discarded the history;\n\nand everybody (including me) now favors to have the history.\n\nSo the answer to your question is yes, but I do not think we heard opinion\nfrom anybody regarding the question by Avery yet.  I personally do not see\nhow it would help us if the old history is rewritten at this point.\n"},{"id":"185565","messageId":"20120227212157.GA19779@sigill.intra.peff.net","threadId":"29603","inReplyTo":"7vobsk56md.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-27T21:21:57Z","receivedAt":"2012-02-27T21:21:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 27, 2012 at 01:06:02PM -0800, Junio C Hamano wrote:\n\n> >>> I'm happy to do either (rebase or filter-branch).  Just let me know.\n> >>\n> >> I would understand Avery's \"should we filter-branch/rebase, or is it OK\n> >> as-is?\", but I do not understand what you mean by \"either rebase or\n> >> filter-branch is fine\".\n> >\n> > Sorry, got mixed up there.  I'm not that familiar with filter-branch.\n> > Now I understand you do both.  :)\n> >\n> > So have we decided to keep the history?\n> \n> I think the discussion so far was:\n> \n>  - Peff suggested to keep the history with a true merge;\n> \n>  - I said the history before the final commit in Avery's tree did not look\n>    so useful for future archaeology; and then\n> \n>  - Avery corrected me that there are contributions by other people and the\n>    credits will be lost if we discarded the history;\n> \n> and everybody (including me) now favors to have the history.\n> \n> So the answer to your question is yes, but I do not think we heard opinion\n> from anybody regarding the question by Avery yet.  I personally do not see\n> how it would help us if the old history is rewritten at this point.\n\nYeah, I don't see much point in rewriting. If parts of the history suck,\nthen so be it.  It's probably not that big to store. And while it's\nsometimes easier to fix bad commit messages when they are recent and in\nyour memory (rather than trying to remember later what you meant to\nsay), I think it is already too late for that. Any archaeology you do\nnow to make good commit messages could probably just as easily be done\nif and when somebody actually needs the commit message later (emphasis\non the \"if\" -- it's likely that nobody will care about most of the\ncommit messages later at all).\n\n-Peff\n"},{"id":"185566","messageId":"20120227212337.GA19864@sigill.intra.peff.net","threadId":"29603","inReplyTo":"20120227212157.GA19779@sigill.intra.peff.net","subject":"Re: git-subtree Ready #2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-27T21:23:38Z","receivedAt":"2012-02-27T21:23:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 27, 2012 at 04:21:57PM -0500, Jeff King wrote:\n\n> > So the answer to your question is yes, but I do not think we heard opinion\n> > from anybody regarding the question by Avery yet.  I personally do not see\n> > how it would help us if the old history is rewritten at this point.\n> \n> Yeah, I don't see much point in rewriting. If parts of the history suck,\n> then so be it.  It's probably not that big to store. And while it's\n> sometimes easier to fix bad commit messages when they are recent and in\n> your memory (rather than trying to remember later what you meant to\n> say), I think it is already too late for that. Any archaeology you do\n> now to make good commit messages could probably just as easily be done\n> if and when somebody actually needs the commit message later (emphasis\n> on the \"if\" -- it's likely that nobody will care about most of the\n> commit messages later at all).\n\nSorry, the \"you\" there is meant to be David. Forgot who I was responding\nto for a minute.\n\n-Peff\n"},{"id":"185586","messageId":"m3ehtfvhkv.fsf@localhost.localdomain","threadId":"29603","inReplyTo":"20120227212157.GA19779@sigill.intra.peff.net","subject":"Re: git-subtree Ready #2","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-28T02:04:51Z","receivedAt":"2012-02-28T02:04:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> \n> Yeah, I don't see much point in rewriting. If parts of the history suck,\n> then so be it.  It's probably not that big to store. And while it's\n> sometimes easier to fix bad commit messages when they are recent and in\n> your memory (rather than trying to remember later what you meant to\n> say), I think it is already too late for that. Any archaeology you do\n> now to make good commit messages could probably just as easily be done\n> if and when somebody actually needs the commit message later (emphasis\n> on the \"if\" -- it's likely that nobody will care about most of the\n> commit messages later at all).\n\nAnyway we already have subtree merges if subsystem with bad error\nmessages -- see gitweb.\n-- \nJakub Narebski\n"},{"id":"185677","messageId":"CAHqTa-2An1Vge-_Zjc8f0ZdgNo3Yd72YxEMSAKQkRaHfJ65n+A@mail.gmail.com","threadId":"29603","inReplyTo":"m3ehtfvhkv.fsf@localhost.localdomain","subject":"Re: git-subtree Ready #2","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2012-02-28T22:42:45Z","receivedAt":"2012-02-28T22:42:45Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Feb 27, 2012 at 9:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>> Yeah, I don't see much point in rewriting. If parts of the history suck,\n>> then so be it.  It's probably not that big to store. And while it's\n>> sometimes easier to fix bad commit messages when they are recent and in\n>> your memory (rather than trying to remember later what you meant to\n>> say), I think it is already too late for that. Any archaeology you do\n>> now to make good commit messages could probably just as easily be done\n>> if and when somebody actually needs the commit message later (emphasis\n>> on the \"if\" -- it's likely that nobody will care about most of the\n>> commit messages later at all).\n>\n> Anyway we already have subtree merges if subsystem with bad error\n> messages -- see gitweb.\n\nSo be it then!  May my lame commit messages persist forever!  As if I\ndon't have enough embarrassing stuff on the Internet.\n\n(Personally I think the vast majority of the commit messages are\nperfectly fine, and the ones that aren't generally describe boring\ncommits anyway, like changes to the 'todo' file.)\n\nHave fun,\n\nAvery\n"},{"id":"185875","messageId":"87mx7zk6s2.fsf@smith.obbligato.org","threadId":"29603","inReplyTo":"7vobsk56md.fsf@alter.siamese.dyndns.org","subject":"Re: git-subtree Ready #2","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2012-03-02T03:42:37Z","receivedAt":"2012-03-02T03:42:37Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> and everybody (including me) now favors to have the history.\n>\n> So the answer to your question is yes, but I do not think we heard opinion\n> from anybody regarding the question by Avery yet.  I personally do not see\n> how it would help us if the old history is rewritten at this point.\n\nLooks like eveyone's on board to keep the history as-is.  I cleaned a\nfew things up and will re-post the subtree once the test-lib.sh \nchanges go through.\n\n                        -Dave\n"}]}