{"thread":{"id":"22606","subject":"[RFC] submodule+shallow clone feature request","startedAt":"2010-02-10T21:39:08Z","lastAt":"2010-02-11T06:51:01Z","messageCount":8,"participants":["Schuyler Duveen","Avery Pennarun","Junio C Hamano","Johannes Schindelin","Peter Hutterer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"134187","messageId":"4B73277C.9010801@columbia.edu","threadId":"22606","inReplyTo":null,"subject":"[RFC] submodule+shallow clone feature request","fromName":"Schuyler Duveen","fromEmail":"sky@columbia.edu","sentAt":"2010-02-10T21:39:08Z","receivedAt":"2010-02-10T21:39:08Z","isPatch":false,"sender":{"key":"sky@columbia.edu","avatar":null},"body":"My use case is deploying from a git repository, which would be even more\ngraceful with the following features:\n\n1. When 'git clone' has both --recursive and --depth, then submodules\nare also checked out shallow (for speed/bandwidth).\n\n2. Some way to specify an override on .gitmodules sources. This is\nbecause our .gitmodules includes public, read-only sources (github),\nrather than our local repos we would prefer to deploy from (for the\npurpose of reliability).\n\nThe other use-case for feature #2 is the read-only vs. writable\nrepository sources. Developers that are also working on the submodules\nshould be able to clone from separate repository sources. Though this\ncould be (and perhaps is) satisfied with a pushurl= in .gitmodules, I'd\nlike to keep the push url non-public, and that still would leave us\nunable to deploy from different urls.\n\nFor #2 maybe something like this:\n\n$ git clone --recursive --depth 1 --modules foo.modules\\\n> git@example.com/foo.git\nwhere foo.modules contains:\n\n[submodule \"bar\"]\n\tpath = bar\n\turl = git@example.com/bar.git\n[submodule \"bar/baz\"]\n\tpath = bar/baz\n\turl = git@example.com/baz.git\n\n\nNotice how the .gitmodules needs to be able to specify recursive sources\nas well. Presumably `git submodule init` would take --modules argument\nas well (and maybe git submodule update, too).\n\nI'm not well-versed in the git source code yet, but poking around\nsuggests that this is doable. Would a patch be well received (or does\nsomeone want to do it for me :-)\n\ncheers,\nsky\n"},{"id":"134189","messageId":"32541b131002101410j3c256dbeg9aa8bacde99886bb@mail.gmail.com","threadId":"22606","inReplyTo":"4B73277C.9010801@columbia.edu","subject":"Re: [RFC] submodule+shallow clone feature request","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-10T22:10:07Z","receivedAt":"2010-02-10T22:10:07Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Feb 10, 2010 at 4:39 PM, Schuyler Duveen wrote:\n> 2. Some way to specify an override on .gitmodules sources.  This is\n> because our .gitmodules includes public, read-only sources (github),\n> rather than our local repos we would prefer to deploy from (for the\n> purpose of reliability).\n\nYou can already override this by editing .git/config after running\n'git submodule init'. Of course, doing so precludes using --recursive\nin \"git clone.\"\n\n> I'm not well-versed in the git source code yet, but poking around\n> suggests that this is doable.  Would a patch be well received (or does\n> someone want to do it for me :-)\n\nThe git-submodule stuff is rarely maintained. I expect patches that\nimprove it will meet with generally positive response, but it's\nsomewhat unlikely that anyone will write them for you.\n\nHave fun,\n\nAvery\n"},{"id":"134190","messageId":"7vsk983fi4.fsf@alter.siamese.dyndns.org","threadId":"22606","inReplyTo":"4B73277C.9010801@columbia.edu","subject":"Re: [RFC] submodule+shallow clone feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-10T22:14:27Z","receivedAt":"2010-02-10T22:14:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Schuyler Duveen writes:\n\n> My use case is deploying from a git repository, which would be even more\n> graceful with the following features:\n>\n> 1. When 'git clone' has both --recursive and --depth, then submodules\n> are also checked out shallow (for speed/bandwidth).\n>\n> 2. Some way to specify an override on .gitmodules sources. This is\n> because our .gitmodules includes public, read-only sources (github),\n> rather than our local repos we would prefer to deploy from (for the\n> purpose of reliability).\n\nThese should be doable if you do not use --recursive, so I don't think\nthey are insurmountable issues. I suspect many people would welcome such\nenhancements to the \"git submodule\" potty.\n\nI think the current implementation of \"--recursive\" is an attempt to help\npeople with a particular view (all submodules are interesting and the user\nneeds an access to them immediately) while not trying to help others with\ndifferent needs. Contribution from the latter class of users to change\nthe situation would be good.\n"},{"id":"134198","messageId":"alpine.DEB.1.00.1002102354010.20986@pacific.mpi-cbg.de","threadId":"22606","inReplyTo":"7vsk983fi4.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] submodule+shallow clone feature request","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-10T22:57:54Z","receivedAt":"2010-02-10T22:57:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 10 Feb 2010, Junio C Hamano wrote:\n\n> Schuyler Duveen writes:\n> \n> > My use case is deploying from a git repository, which would be even more\n> > graceful with the following features:\n> >\n> > 1. When 'git clone' has both --recursive and --depth, then submodules\n> > are also checked out shallow (for speed/bandwidth).\n> >\n> > 2. Some way to specify an override on .gitmodules sources. This is\n> > because our .gitmodules includes public, read-only sources (github),\n> > rather than our local repos we would prefer to deploy from (for the\n> > purpose of reliability).\n> \n> These should be doable if you do not use --recursive, so I don't think \n> they are insurmountable issues. I suspect many people would welcome \n> such enhancements to the \"git submodule\" potty.\n\nYes. Note, though, that the problems of enhancing git-submodule are not \ntechnical, as we can learn from the recent history, including the lack of \nsupport for rebasing submodules (there _were_ patches!).\n\nCiao,\nDscho\n"},{"id":"134199","messageId":"7v1vgszo16.fsf@alter.siamese.dyndns.org","threadId":"22606","inReplyTo":"alpine.DEB.1.00.1002102354010.20986@pacific.mpi-cbg.de","subject":"Re: [RFC] submodule+shallow clone feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-10T23:09:09Z","receivedAt":"2010-02-10T23:09:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Yes. Note, though, that the problems of enhancing git-submodule are not \n> technical, as we can learn from the recent history, including the lack of \n> support for rebasing submodules (there _were_ patches!).\n\nSorry I don't recall. Were they of 'next' quality? How well were they\nreviewed?\n"},{"id":"134202","messageId":"alpine.DEB.1.00.1002110057180.20986@pacific.mpi-cbg.de","threadId":"22606","inReplyTo":"7v1vgszo16.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] submodule+shallow clone feature request","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-10T23:59:54Z","receivedAt":"2010-02-10T23:59:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 10 Feb 2010, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Yes. Note, though, that the problems of enhancing git-submodule are \n> > not technical, as we can learn from the recent history, including the \n> > lack of support for rebasing submodules (there _were_ patches!).\n> \n> Sorry I don't recall. Were they of 'next' quality? How well were they \n> reviewed?\n\nObviously not, otherwise you would have applied them, no?\n\nOTOH I found the technical details rather trivial, so maybe they were \n'next' quality, but there was another reason you did not apply them.\n\nI just know that from my daily workflow, I deeply miss rebasing \nsubmodules. But then, I listed the issues I have with submodules, and this \nlist was welcomed with unbelievable enthusiasm.\n\nCiao,\nDscho\n"},{"id":"134207","messageId":"7v8wb0l2f5.fsf@alter.siamese.dyndns.org","threadId":"22606","inReplyTo":"alpine.DEB.1.00.1002110057180.20986@pacific.mpi-cbg.de","subject":"Re* [RFC] submodule+shallow clone feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-11T06:19:42Z","receivedAt":"2010-02-11T06:19:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 10 Feb 2010, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > Yes. Note, though, that the problems of enhancing git-submodule are \n>> > not technical, as we can learn from the recent history, including the \n>> > lack of support for rebasing submodules (there _were_ patches!).\n>> \n>> Sorry I don't recall. Were they of 'next' quality? How well were they \n>> reviewed?\n>\n> Obviously not, otherwise you would have applied them, no?\n>\n> OTOH I found the technical details rather trivial, so maybe they were \n> 'next' quality, but there was another reason you did not apply them.\n\nWell, I spent some time digging the mail archive myself. I think you were\ntalking about this thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/116918\n\nIf this is not the thread you were talking about, please discard/disregard\nthe remainder of this message, and give me a better pointer instead.\n\nThe thread ends with you asking me:\n\n Junio, how about it? post 1.6.3 or not? It is a well contained change, \n with little chance of breaking something, but offers a more sensible \n workflow here.\n\nand I said:\n\n I am afraid it is a bit too late for \"improvements\" after -rc1.\n People survived without the new feature until now, and they can wait a\n bit longer for the next one....\n\nObviously, after that nothing happened. We have some people who send\nreminders for good topics after the original thread died without producing\na visible result. I'd ask you to do the same (when you can---as everybody\nelse, you don't work full time on git; neither do I).\n\nAn honest answer to my question would have been \"Yes, I reviewed it and\nmentored the original author through a few cycles of revisions. After\nthat process the patch was of 'next' quality. This however happened\nduring the pre-release freeze, and unfortunately nobody (including you or\nI) rememebered to bring up the issue again after the release to move\nthings forward. It fell through cracks.\"\n\nInstead, what you wrote makes it sounds as if I blocked a technically\ncorrect solution to a real problem on some political grounds, doesn't it?\nWhat effect did you hope your insinuation to have on readers of this list?\n\nIt does not help to give a new person a false impression that it takes\nmore than producing a good solution to a real problem to contribute to the\nproject. Especially, the \"falling through the crack\" didn't have anything\nto do with it being submodule changes. Please stop spreading FUD and try\nto be constructive as others do.\n\nTo restart the discussion so that we can have it (if it is a good change)\nafter 1.7.0 ships, here is a pointer to the last revision of the patch.\n\n http://article.gmane.org/gmane.comp.version-control.git/117394/raw\n\nI didn't check if it needs rebasing to the recent codebase, but I expect\npeople who work with submodules in real life (I don't count) to comment on\nit, and re-polish it into an applicable shape if necessary, by the time\npost 1.7.0 cycle opens.\n\n-- >8 --\nFrom: Peter Hutterer \nSubject: Re: [PATCH/RESEND] git-submodule: add support for --rebase.\nDate: Fri, 24 Apr 2009 09:06:38 +1000\n\n'git submodule update --rebase' rebases your local branch on top of what\nwould have been checked out to a detached HEAD otherwise.\n\nIn some cases, detaching the HEAD when updating a submodule complicates\nthe workflow to commit to this submodule (checkout master, rebase, then\ncommit). For submodules that require frequent updates but infrequent\n(if any) commits, a rebase can be executed directly by the git-submodule\ncommand, ensuring that the submodules stay on their respective branches.\n\ngit-config key: submodule.$name.rebase (bool)\n\nSigned-off-by: Peter Hutterer \nSigned-off-by: Johannes Schindelin \n---\n\n> With this squashed in, I actually would not be too opposed to put this \n> into 1.6.3, as it _is_ an improvement.\n> \n> -- snipsnap --\n> [PATCH] To be squashed in\n> \n> This does three things:\n> \n> - add .gitmodules support for rebase,\n> - use --bool for the git config calls for type checking, and\n> - rename ambiguous t7404 to t7406.\n> \n> Signed-off-by: Johannes Schindelin \n\nSquashed in, thank you. One typo fixed in last testcase (does-not-mater ->\ndoes-not-matter).\n\n Documentation/git-submodule.txt | 14 ++++-\n Documentation/gitmodules.txt | 3 +\n git-submodule.sh | 33 ++++++++-\n t/t7406-submodule-update.sh | 140 +++++++++++++++++++++++++++++++++++++++\n 4 files changed, 184 insertions(+), 6 deletions(-)\n create mode 100755 t/t7406-submodule-update.sh\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 3b8df44..0286409 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git submodule' [--quiet] add [-b branch] [--] \n 'git submodule' [--quiet] status [--cached] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--] [...]\n+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--] [...]\n 'git submodule' [--quiet] summary [--summary-limit ] [commit] [--] [...]\n 'git submodule' [--quiet] foreach \n 'git submodule' [--quiet] sync [--] [...]\n@@ -113,7 +113,8 @@ init::\n update::\n \tUpdate the registered submodules, i.e. clone missing submodules and\n \tcheckout the commit specified in the index of the containing repository.\n-\tThis will make the submodules HEAD be detached.\n+\tThis will make the submodules HEAD be detached unless '--rebase' is\n+\tspecified or the key `submodule.$name.rebase` is set to `true`.\n +\n If the submodule is not yet initialized, and you just want to use the\n setting as stored in .gitmodules, you can automatically initialize the\n@@ -177,6 +178,15 @@ OPTIONS\n \tThis option is only valid for the update command.\n \tDon't fetch new objects from the remote site.\n \n+--rebase::\n+\tThis option is only valid for the update command.\n+\tRebase the current branch onto the commit recorded in the\n+\tsuperproject. If this option is given, the submodule's HEAD will not\n+\tbe detached. If a a merge failure prevents this process, you will have\n+\tto resolve these failures with linkgit:git-rebase[1].\n+\tIf the key `submodule.$name.rebase` is set to `true`, this option is\n+\timplicit.\n+\n ...::\n \tPaths to submodule(s). When specified this will restrict the command\n \tto only operate on the submodules found at the specified paths.\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex d1a17e2..7c22c40 100644\n--- a/Documentation/gitmodules.txt\n+++ b/Documentation/gitmodules.txt\n@@ -30,6 +30,9 @@ submodule..path::\n submodule..url::\n \tDefines an url from where the submodule repository can be cloned.\n \n+submodule..rebase::\n+\tDefines that the submodule should be rebased by default.\n+\n \n EXAMPLES\n --------\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 7c2e060..b7c9bdc 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -17,6 +17,7 @@ branch=\n quiet=\n cached=\n nofetch=\n+rebase=\n \n #\n # print stuff on stdout unless -q was specified\n@@ -287,6 +288,11 @@ cmd_init()\n \t\tgit config submodule.\"$name\".url \"$url\" ||\n \t\tdie \"Failed to register url for submodule path '$path'\"\n \n+\t\ttest true != \"$(git config -f .gitmodules --bool \\\n+\t\t\tsubmodule.\"$name\".rebase)\" ||\n+\t\tgit config submodule.\"$name\".rebase true ||\n+\t\tdie \"Failed to register submodule path '$path' as rebasing\"\n+\n \t\tsay \"Submodule '$name' ($url) registered for path '$path'\"\n \tdone\n }\n@@ -314,6 +320,10 @@ cmd_update()\n \t\t\tshift\n \t\t\tnofetch=1\n \t\t\t;;\n+\t\t-r|--rebase)\n+\t\t\tshift\n+\t\t\trebase=true\n+\t\t\t;;\n \t\t--)\n \t\t\tshift\n \t\t\tbreak\n@@ -332,6 +342,7 @@ cmd_update()\n \tdo\n \t\tname=$(module_name \"$path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n+\t\trebase_module=$(git config --bool submodule.\"$name\".rebase)\n \t\tif test -z \"$url\"\n \t\tthen\n \t\t\t# Only mention uninitialized submodules when its\n@@ -352,6 +363,11 @@ cmd_update()\n \t\t\tdie \"Unable to find current revision in submodule path '$path'\"\n \t\tfi\n \n+\t\tif test true = \"$rebase\"\n+\t\tthen\n+\t\t\trebase_module=true\n+\t\tfi\n+\n \t\tif test \"$subsha1\" != \"$sha1\"\n \t\tthen\n \t\t\tforce=\n@@ -367,11 +383,20 @@ cmd_update()\n \t\t\t\tdie \"Unable to fetch in submodule path '$path'\"\n \t\t\tfi\n \n-\t\t\t(unset GIT_DIR; cd \"$path\" &&\n-\t\t\t\t git-checkout $force -q \"$sha1\") ||\n-\t\t\tdie \"Unable to checkout '$sha1' in submodule path '$path'\"\n+\t\t\tif test true = \"$rebase_module\"\n+\t\t\tthen\n+\t\t\t\tcommand=\"git-rebase\"\n+\t\t\t\taction=\"rebase\"\n+\t\t\t\tmsg=\"rebased onto\"\n+\t\t\telse\n+\t\t\t\tcommand=\"git-checkout $force -q\"\n+\t\t\t\taction=\"checkout\"\n+\t\t\t\tmsg=\"checked out\"\n+\t\t\tfi\n \n-\t\t\tsay \"Submodule path '$path': checked out '$sha1'\"\n+\t\t\t(unset GIT_DIR; cd \"$path\" && $command \"$sha1\") ||\n+\t\t\tdie \"Unable to $action '$sha1' in submodule path '$path'\"\n+\t\t\tsay \"Submodule path '$path': $msg '$sha1'\"\n \t\tfi\n \tdone\n }\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nnew file mode 100755\nindex 0000000..3442c05\n--- /dev/null\n+++ b/t/t7406-submodule-update.sh\n@@ -0,0 +1,140 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2009 Red Hat, Inc.\n+#\n+\n+test_description='Test updating submodules\n+\n+This test verifies that \"git submodule update\" detaches the HEAD of the\n+submodule and \"git submodule update --rebase\" does not detach the HEAD.\n+'\n+\n+. ./test-lib.sh\n+\n+\n+compare_head()\n+{\n+ sha_master=`git-rev-list --max-count=1 master`\n+ sha_head=`git-rev-list --max-count=1 HEAD`\n+\n+ test \"$sha_master\" = \"$sha_head\"\n+}\n+\n+\n+test_expect_success 'setup a submodule tree' '\n+\techo file > file &&\n+\tgit add file &&\n+\ttest_tick &&\n+\tgit commit -m upstream\n+\tgit clone . super &&\n+\tgit clone super submodule &&\n+\t(cd super &&\n+\t git submodule add ../submodule submodule &&\n+\t test_tick &&\n+\t git commit -m \"submodule\" &&\n+\t git submodule init submodule\n+\t) &&\n+\t(cd submodule &&\n+\techo \"line2\" > file &&\n+\tgit add file &&\n+\tgit commit -m \"Commit 2\"\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t git pull --rebase origin\n+\t ) &&\n+\t git add submodule &&\n+\t git commit -m \"submodule update\"\n+\t)\n+'\n+\n+test_expect_success 'submodule update detaching the HEAD ' '\n+\t(cd super/submodule &&\n+\t git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update submodule &&\n+\t cd submodule &&\n+\t ! compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update --rebase staying on master' '\n+\t(cd super/submodule &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update --rebase submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - rebase true in .git/config' '\n+\t(cd super &&\n+\t git config submodule.submodule.rebase true\n+\t) &&\n+\t(cd super/submodule &&\n+\t git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - rebase false in .git/config but --rebase given' '\n+\t(cd super &&\n+\t git config submodule.submodule.rebase false\n+\t) &&\n+\t(cd super/submodule &&\n+\t git reset --hard HEAD~1\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update --rebase submodule &&\n+\t cd submodule &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update - rebase false in .git/config' '\n+\t(cd super &&\n+\t git config submodule.submodule.rebase false\n+\t) &&\n+\t(cd super/submodule &&\n+\t git reset --hard HEAD^\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update submodule &&\n+\t cd submodule &&\n+\t ! compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule init picks up rebase' '\n+\t(cd super &&\n+\t git config submodule.rebasing.url git://non-existing/git &&\n+\t git config submodule.rebasing.path does-not-matter &&\n+\t git config submodule.rebasing.rebase true &&\n+\t git submodule init rebasing &&\n+\t test true = $(git config --bool submodule.rebasing.rebase)\n+\t)\n+'\n+\n+test_done\n-- \n1.6.3.rc1.2.gfa66a\n"},{"id":"134208","messageId":"20100211065101.GA12261@barra.bne.redhat.com","threadId":"22606","inReplyTo":"7v8wb0l2f5.fsf@alter.siamese.dyndns.org","subject":"Re: Re* [RFC] submodule+shallow clone feature request","fromName":"Peter Hutterer","fromEmail":"peter.hutterer@who-t.net","sentAt":"2010-02-11T06:51:01Z","receivedAt":"2010-02-11T06:51:01Z","isPatch":false,"sender":{"key":"peter.hutterer@who-t.net","avatar":"https://avatars.githubusercontent.com/u/1487352?v=4"},"body":"On Wed, Feb 10, 2010 at 10:19:42PM -0800, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > On Wed, 10 Feb 2010, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> > Yes. Note, though, that the problems of enhancing git-submodule are \n> >> > not technical, as we can learn from the recent history, including the \n> >> > lack of support for rebasing submodules (there _were_ patches!).\n> >> \n> >> Sorry I don't recall. Were they of 'next' quality? How well were they \n> >> reviewed?\n> >\n> > Obviously not, otherwise you would have applied them, no?\n> >\n> > OTOH I found the technical details rather trivial, so maybe they were \n> > 'next' quality, but there was another reason you did not apply them.\n> \n> Well, I spent some time digging the mail archive myself. I think you were\n> talking about this thread:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/116918\n> \n> If this is not the thread you were talking about, please discard/disregard\n> the remainder of this message, and give me a better pointer instead.\n> \n> The thread ends with you asking me:\n> \n> Junio, how about it? post 1.6.3 or not? It is a well contained change, \n> with little chance of breaking something, but offers a more sensible \n> workflow here.\n> \n> and I said:\n> \n> I am afraid it is a bit too late for \"improvements\" after -rc1.\n> People survived without the new feature until now, and they can wait a\n> bit longer for the next one....\n> \n> Obviously, after that nothing happened. We have some people who send\n> reminders for good topics after the original thread died without producing\n> a visible result. I'd ask you to do the same (when you can---as everybody\n> else, you don't work full time on git; neither do I).\n\n[...]\n\n> To restart the discussion so that we can have it (if it is a good change)\n> after 1.7.0 ships, here is a pointer to the last revision of the patch.\n> \n> http://article.gmane.org/gmane.comp.version-control.git/117394/raw\n\nThanks for CCing me, I'm not on the list at the moment.\nFWIW, Johannes pinged me about this patch a few weeks after that, but after\nrevisiting it a few times I found some issues with it. Here's the email I\nsent to Johannes on April 24, my apologies that this was a private email\nonly and did not reach the list.\n\n\"Sorry about the delay again, I've been a bit busy lately.\nI've thought about it a bit more and tbh. I don't think this patch - even if\nrebased - should be merged.\n\nThe original idea was that a module can be marked for auto-rebasing in\n.gitmodules. The issue with that is that AFAIK git submodule does not store\nbranch info. So such auto-rebasing would only work provided it would be on\nthe master branch. Anything else would require a fancier script than my\npatch including specifying which branch should be checked out in the\noriginal clone.\n\nRight now, I don't have the time to design such a patch and I'm not even\nsure how much it is needed.\nWith git submodule foreach it's relatively simple to just do the auto-rebase\nsetting for all modules and I would not be surprised if the majority of\nuse-cases require auto-rebasing on all modules anyway.\n\nDoes that make sense?\n\"\n\nSo in this particular case the patchset was withdrawn by me for technical\nreasons (and the lack of time to sort out the details). It should have\ncommunicated better - again, my apologies for that.\n\nCheers,\n Peter\n"}]}