{"thread":{"id":"34294","subject":"[RFC/PATCH] submodule: add 'exec' option to submodule update","startedAt":"2013-06-28T09:53:10Z","lastAt":"2013-07-03T17:17:50Z","messageCount":19,"participants":["Chris Packham","Stefan Näwe","Fredrik Gustafsson","Jens Lehmann","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"222159","messageId":"1372413190-32732-1-git-send-email-judge.packham@gmail.com","threadId":"34294","inReplyTo":null,"subject":"[RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-06-28T09:53:10Z","receivedAt":"2013-06-28T09:53:10Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"This allows the user some finer grained control over how the update is\ndone. The primary motivation for this was interoperability with stgit\nhowever being able to intercept the submodule update process may prove\nuseful for integrating or extending other tools.\n\nSigned-off-by: Chris Packham <judge.packham@gmail.com>\n--\nHi,\n\nAt $dayjob we have a number of users that are accustomed to using stgit.\nStgit doesn't play nicely with git rebase which would be the logical\nsetting for submodule.*.update for our usage. Instead we need to run\n'stg rebase --merged' on those submodules that have been initialised\nwith stgit.\n\nOur current solution is an in-house script which is a poor substitute\nfor git submodule update. I'd much rather replace our script with git\nsubmodule update but we do have a requirement to keep stgit for the\nforeseeable future.  Rather than narrowing in on stgit it seems logical\nto allow an arbitrary update command to be executed.\n---\n Documentation/git-submodule.txt |  8 +++++++-\n git-submodule.sh                | 22 +++++++++++++++++++++-\n 2 files changed, 28 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex e576713..a0d8b89 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -16,7 +16,7 @@ SYNOPSIS\n 'git submodule' [--quiet] deinit [-f|--force] [--] <path>...\n 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]\n \t      [-f|--force] [--rebase] [--reference <repository>]\n-\t      [--merge] [--recursive] [--] [<path>...]\n+\t      [--merge] [--recursive] [--exec <command>] [--] [<path>...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]\n \t      [commit] [--] [<path>...]\n 'git submodule' [--quiet] foreach [--recursive] <command>\n@@ -172,6 +172,12 @@ If `--force` is specified, the submodule will be checked out (using\n `git checkout --force` if appropriate), even if the commit specified in the\n index of the containing repository already matches the commit checked out in\n the submodule.\n++\n+If `--exec` is specified the next argument is an arbitrary shell command that\n+can be used to gain finer control over how the update is done or integrate with\n+external tools. The command should take one argument namely the sha1 of the\n+commit to update to. The config variable `submodule.$name.update` can be set\n+to `exec` along with `submodule.$name.update.command`.\n \n summary::\n \tShow commit summary between the given commit (defaults to HEAD) and\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex eb58c8e..44631c8 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -9,7 +9,7 @@ USAGE=\"[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <re\n    or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n    or: $dashless [--quiet] init [--] [<path>...]\n    or: $dashless [--quiet] deinit [-f|--force] [--] <path>...\n-   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n+   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--exec <command>] [--] [<path>...]\n    or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]\n    or: $dashless [--quiet] foreach [--recursive] <command>\n    or: $dashless [--quiet] sync [--recursive] [--] [<path>...]\"\n@@ -32,6 +32,7 @@ nofetch=\n update=\n prefix=\n custom_name=\n+update_exec_command=\n \n # The function takes at most 2 arguments. The first argument is the\n # URL that navigates to the submodule origin repo. When relative, this URL\n@@ -677,6 +678,12 @@ cmd_update()\n \t\t--checkout)\n \t\t\tupdate=\"checkout\"\n \t\t\t;;\n+\t\t--exec)\n+\t\t\tcase \"$2\" in '') usage ;; esac\n+\t\t\tupdate=\"exec\"\n+\t\t\tupdate_exec_command=\"$2\"\n+\t\t\tshift\n+\t\t\t;;\n \t\t--)\n \t\t\tshift\n \t\t\tbreak\n@@ -718,6 +725,11 @@ cmd_update()\n \t\t\tupdate_module=$(git config submodule.\"$name\".update)\n \t\tfi\n \n+\t\tif test -z \"$update_exec_command\"\n+\t\tthen\n+\t\t\texec_command=$(git config submodule.\"$name\".update.command)\n+\t\tfi\n+\n \t\tif test \"$update_module\" = \"none\"\n \t\tthen\n \t\t\techo \"Skipping submodule '$prefix$sm_path'\"\n@@ -799,6 +811,14 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n \t\t\t\tmust_die_on_failure=yes\n \t\t\t\t;;\n+\t\t\texec)\n+\t\t\t\ttest -n \"$exec_command\" || \\\n+\t\t\t\t\tdie \"$(eval_gettext \"Unable to update '\\$prefix\\$sm_path' exec command not specified\")\"\n+\t\t\t\tcommand=\"$exec_command\"\n+\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n+\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n+\t\t\t\tmust_die_on_failure=yes\n+\t\t\t\t;;\n \t\t\t*)\n \t\t\t\tcommand=\"git checkout $subforce -q\"\n \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n-- \n1.8.3.1.643.gebeea52.dirty\n"},{"id":"222160","messageId":"51CD61AD.4090203@atlas-elektronik.com","threadId":"34294","inReplyTo":"1372413190-32732-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Stefan Näwe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2013-06-28T10:13:01Z","receivedAt":"2013-06-28T10:13:01Z","isPatch":true,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Am 28.06.2013 11:53, schrieb Chris Packham:\n> This allows the user some finer grained control over how the update is\n> done. The primary motivation for this was interoperability with stgit\n> however being able to intercept the submodule update process may prove\n> useful for integrating or extending other tools.\n> \n> Signed-off-by: Chris Packham <judge.packham@gmail.com>\n> --\n> Hi,\n> \n> At $dayjob we have a number of users that are accustomed to using stgit.\n> Stgit doesn't play nicely with git rebase which would be the logical\n> setting for submodule.*.update for our usage. Instead we need to run\n> 'stg rebase --merged' on those submodules that have been initialised\n> with stgit.\n> \n> Our current solution is an in-house script which is a poor substitute\n> for git submodule update. I'd much rather replace our script with git\n> submodule update but we do have a requirement to keep stgit for the\n> foreseeable future.  Rather than narrowing in on stgit it seems logical\n> to allow an arbitrary update command to be executed.\n\nHhmmm...\nCan't the same be accomplished with \n \n  git submodule foreach 'your-update-script $sha1'\n\nAm I missing something?\n\nStefan\n-- \n----------------------------------------------------------------\n/dev/random says: Preserve nature... pickle a squirrel.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\"\n"},{"id":"222162","messageId":"20130628104243.GD27497@paksenarrion.iveqy.com","threadId":"34294","inReplyTo":"1372413190-32732-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-06-28T10:42:43Z","receivedAt":"2013-06-28T10:42:43Z","isPatch":true,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"Hi,\n\nOn Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote:\n> This allows the user some finer grained control over how the update is\n> done. The primary motivation for this was interoperability with stgit\n> however being able to intercept the submodule update process may prove\n> useful for integrating or extending other tools.\n> \n> Signed-off-by: Chris Packham <judge.packham@gmail.com>\n> --\n> Hi,\n> \n> At $dayjob we have a number of users that are accustomed to using stgit.\n> Stgit doesn't play nicely with git rebase which would be the logical\n> setting for submodule.*.update for our usage. Instead we need to run\n> 'stg rebase --merged' on those submodules that have been initialised\n> with stgit.\n> \n> Our current solution is an in-house script which is a poor substitute\n> for git submodule update. I'd much rather replace our script with git\n> submodule update but we do have a requirement to keep stgit for the\n> foreseeable future.  Rather than narrowing in on stgit it seems logical\n> to allow an arbitrary update command to be executed.\n> ---\n>  Documentation/git-submodule.txt |  8 +++++++-\n>  git-submodule.sh                | 22 +++++++++++++++++++++-\n>  2 files changed, 28 insertions(+), 2 deletions(-)\n> \n\ntechnically it looks fine to me (except for the lack of tests) but I'm\nnot sure I follow the use case.\n\nIn your case, you want to run a script to determinate if that certain\nsubmodule should use merge or rebase depending on \"whatever\". And this\ncan't be done with git submodule foreach because you want to know the\nsha1 to update to. Have I understood you correctly?\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"222226","messageId":"51CEA4B2.1090008@gmail.com","threadId":"34294","inReplyTo":"20130628104243.GD27497@paksenarrion.iveqy.com","subject":"Re: [RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-06-29T09:11:14Z","receivedAt":"2013-06-29T09:11:14Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 28/06/13 22:42, Fredrik Gustafsson wrote:\n> Hi,\n> \n> On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote:\n>> This allows the user some finer grained control over how the update is\n>> done. The primary motivation for this was interoperability with stgit\n>> however being able to intercept the submodule update process may prove\n>> useful for integrating or extending other tools.\n>>\n>> Signed-off-by: Chris Packham <judge.packham@gmail.com>\n>> --\n>> Hi,\n>>\n>> At $dayjob we have a number of users that are accustomed to using stgit.\n>> Stgit doesn't play nicely with git rebase which would be the logical\n>> setting for submodule.*.update for our usage. Instead we need to run\n>> 'stg rebase --merged' on those submodules that have been initialised\n>> with stgit.\n>>\n>> Our current solution is an in-house script which is a poor substitute\n>> for git submodule update. I'd much rather replace our script with git\n>> submodule update but we do have a requirement to keep stgit for the\n>> foreseeable future.  Rather than narrowing in on stgit it seems logical\n>> to allow an arbitrary update command to be executed.\n>> ---\n>>  Documentation/git-submodule.txt |  8 +++++++-\n>>  git-submodule.sh                | 22 +++++++++++++++++++++-\n>>  2 files changed, 28 insertions(+), 2 deletions(-)\n>>\n> \n> technically it looks fine to me (except for the lack of tests) but I'm\n> not sure I follow the use case.\n> \n> In your case, you want to run a script to determinate if that certain\n> submodule should use merge or rebase depending on \"whatever\". And this\n> can't be done with git submodule foreach because you want to know the\n> sha1 to update to. Have I understood you correctly?\n>\n\nCorrect. We tend to have submodules that are just normal detached heads\nwhich we don't usually touch and others that are actively developed\nwhere we would use submodule.x.update=rebase (I personally do) but some\ndevelopers want to use stgit on those repositories.\n\nAnother approach could be to do a 'git pull --no-recurse-submodule' then\nuse 'git submodule foreach script-that-does-the-rebase'. The benefit of\nthe patch I sent is that it can be setup using the config variables[1]\nand updated the normal way along with the detached HEADs and those using\nplain git branches.\n\nThere may be other use-cases for integration with other tools as well\n(e.g. something that updates a review tool when commits get rebased).\n\n--\n[1] I'm not crazy about the name of submodule.*.update.command but I\ncouldn't think of a better one.\n"},{"id":"222254","messageId":"51D04F06.9000400@web.de","threadId":"34294","inReplyTo":"51CEA4B2.1090008@gmail.com","subject":"Re: [RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-06-30T15:30:14Z","receivedAt":"2013-06-30T15:30:14Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 29.06.2013 11:11, schrieb Chris Packham:\n> On 28/06/13 22:42, Fredrik Gustafsson wrote:\n>> technically it looks fine to me (except for the lack of tests) but I'm\n>> not sure I follow the use case.\n>>\n>> In your case, you want to run a script to determinate if that certain\n>> submodule should use merge or rebase depending on \"whatever\". And this\n>> can't be done with git submodule foreach because you want to know the\n>> sha1 to update to. Have I understood you correctly?\n> \n> Correct. We tend to have submodules that are just normal detached heads\n> which we don't usually touch and others that are actively developed\n> where we would use submodule.x.update=rebase (I personally do) but some\n> developers want to use stgit on those repositories.\n> \n> Another approach could be to do a 'git pull --no-recurse-submodule' then\n> use 'git submodule foreach script-that-does-the-rebase'. The benefit of\n> the patch I sent is that it can be setup using the config variables[1]\n> and updated the normal way along with the detached HEADs and those using\n> plain git branches.\n\nWouldn't a \"stgit submodule update\" (which would do the Right Thing for\nsubmodules initialized with stgit by maybe just using the pull & foreach\nlogic you described) be a better UI for solving your problem?\n\n> There may be other use-cases for integration with other tools as well\n> (e.g. something that updates a review tool when commits get rebased).\n> \n> --\n> [1] I'm not crazy about the name of submodule.*.update.command but I\n> couldn't think of a better one.\n\nHmm, if we go that route, why not do the same we do for aliases? If\nthe submodule.*.update setting is prefixed with a '!', we just execute\nthe shell command following. This would give everyone the freedom to\ndo arbitrary stuff if the current none, checkout, merge & rebase won't\ndo the trick without having to add another config option.\n"},{"id":"222272","messageId":"51D14A05.7030707@gmail.com","threadId":"34294","inReplyTo":"51D04F06.9000400@web.de","subject":"Re: [RFC/PATCH] submodule: add 'exec' option to submodule update","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-01T09:21:09Z","receivedAt":"2013-07-01T09:21:09Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 01/07/13 03:30, Jens Lehmann wrote:\n> Am 29.06.2013 11:11, schrieb Chris Packham:\n>> On 28/06/13 22:42, Fredrik Gustafsson wrote:\n>>> technically it looks fine to me (except for the lack of tests) but I'm\n>>> not sure I follow the use case.\n>>>\n>>> In your case, you want to run a script to determinate if that certain\n>>> submodule should use merge or rebase depending on \"whatever\". And this\n>>> can't be done with git submodule foreach because you want to know the\n>>> sha1 to update to. Have I understood you correctly?\n>>\n>> Correct. We tend to have submodules that are just normal detached heads\n>> which we don't usually touch and others that are actively developed\n>> where we would use submodule.x.update=rebase (I personally do) but some\n>> developers want to use stgit on those repositories.\n>>\n>> Another approach could be to do a 'git pull --no-recurse-submodule' then\n>> use 'git submodule foreach script-that-does-the-rebase'. The benefit of\n>> the patch I sent is that it can be setup using the config variables[1]\n>> and updated the normal way along with the detached HEADs and those using\n>> plain git branches.\n> \n> Wouldn't a \"stgit submodule update\" (which would do the Right Thing for\n> submodules initialized with stgit by maybe just using the pull & foreach\n> logic you described) be a better UI for solving your problem?\n\nYeah I guess so. I was hoping to stay away from an stgit specific\nsolution but I'm not hearing any other voices looking for such flexibility.\n\n>> There may be other use-cases for integration with other tools as well\n>> (e.g. something that updates a review tool when commits get rebased).\n>>\n>> --\n>> [1] I'm not crazy about the name of submodule.*.update.command but I\n>> couldn't think of a better one.\n> \n> Hmm, if we go that route, why not do the same we do for aliases? If\n> the submodule.*.update setting is prefixed with a '!', we just execute\n> the shell command following. This would give everyone the freedom to\n> do arbitrary stuff if the current none, checkout, merge & rebase won't\n> do the trick without having to add another config option.\n>\n\nMake sense. I'll give it a go.\n"},{"id":"222273","messageId":"1372673494-24286-1-git-send-email-judge.packham@gmail.com","threadId":"34294","inReplyTo":"51D04F06.9000400@web.de","subject":"[RFC/PATCHv2] submodule: add ability to configure update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-01T10:11:34Z","receivedAt":"2013-07-01T10:11:34Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Users can set submodule.$name.update to '!command' which will cause\n'command' to be run instead of checkout/merge/rebase.  This allows the\nuser some finer grained control over how the update is done. The primary\nmotivation for this was interoperability with stgit however being able\nto intercept the submodule update process may prove useful for\nintegrating or extending other tools.\n\nSigned-off-by: Chris Packham <judge.packham@gmail.com>\n---\n\nOn 01/07/13 03:30, Jens Lehmann wrote:\n>\n> Hmm, if we go that route, why not do the same we do for aliases? If\n> the submodule.*.update setting is prefixed with a '!', we just execute\n> the shell command following. This would give everyone the freedom to\n> do arbitrary stuff if the current none, checkout, merge & rebase won't\n> do the trick without having to add another config option.\n>\n\nAnd here's an implementation of this. Actually I like this a lot better\nto the v1 patch. Still lacks tests but if there is enough interest I can\nadd some.\n\n Documentation/git-submodule.txt | 5 ++++-\n git-submodule.sh                | 6 ++++++\n 2 files changed, 10 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex e576713..0befc20 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -159,7 +159,9 @@ update::\n \tThis will make the submodules HEAD be detached unless `--rebase` or\n \t`--merge` is specified or the key `submodule.$name.update` is set to\n \t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n-\t`--checkout`.\n+\t`--checkout`. Setting the key `submodule.$name.update` to `!command`\n+\twill cause `command` to be run. `command` can be any arbitrary shell\n+\tcommand that takes a single argument, namely the sha1 to update to.\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@@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n `git checkout --force` if appropriate), even if the commit specified in the\n index of the containing repository already matches the commit checked out in\n the submodule.\n++\n \n summary::\n \tShow commit summary between the given commit (defaults to HEAD) and\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex eb58c8e..680cb68 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n \t\t\t\tmust_die_on_failure=yes\n \t\t\t\t;;\n+\t\t\t!*)\n+\t\t\t\tcommand=\"$(expr \"$update_module\" : '!\\(.*\\)')\"\n+\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n+\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n+\t\t\t\tmust_die_on_failure=yes\n+\t\t\t\t;;\n \t\t\t*)\n \t\t\t\tcommand=\"git checkout $subforce -q\"\n \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n-- \n1.8.3.1.644.g533062f.dirty\n"},{"id":"222283","messageId":"7vehbii6un.fsf@alter.siamese.dyndns.org","threadId":"34294","inReplyTo":"1372673494-24286-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCHv2] submodule: add ability to configure update command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-01T16:26:56Z","receivedAt":"2013-07-01T16:26:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> Subject: Re: [RFC/PATCHv2] submodule: add ability to configure update command\n\n\"ability to configure\" wants to be rephrased to make it more useful\nin the shortlog output to help me update release notes ;-)\n\n    Subject: [PATCH] submodule update: allow custom update command\n\nperhaps?  We already allow you to configure update command between\nmerge, rebase and checkout-to-detach, and the value of the change is\nto let an arbitrary custom command to be used there.\n\n> And here's an implementation of this. Actually I like this a lot better\n> to the v1 patch.\n\nI agree that this looks much more sensible.\n\nThanks.\n"},{"id":"222286","messageId":"7v1u7ii5us.fsf@alter.siamese.dyndns.org","threadId":"34294","inReplyTo":"1372673494-24286-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCHv2] submodule: add ability to configure update command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-01T16:48:27Z","receivedAt":"2013-07-01T16:48:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> +\t\t\t!*)\n> +\t\t\t\tcommand=\"$(expr \"$update_module\" : '!\\(.*\\)')\"\n\n\tcommand=${command#!}\n"},{"id":"222363","messageId":"51D2A475.9010608@gmail.com","threadId":"34294","inReplyTo":"7v1u7ii5us.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCHv2] submodule: add ability to configure update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-02T09:59:17Z","receivedAt":"2013-07-02T09:59:17Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 02/07/13 04:48, Junio C Hamano wrote:\n> Chris Packham <judge.packham@gmail.com> writes:\n> \n>> +\t\t\t!*)\n>> +\t\t\t\tcommand=\"$(expr \"$update_module\" : '!\\(.*\\)')\"\n> \n> \tcommand=${command#!}\n> \n\nThanks, expr was my attempt to avoid using a ${command:1} bash-ism. v3\non it's way.\n"},{"id":"222364","messageId":"1372759974-19765-1-git-send-email-judge.packham@gmail.com","threadId":"34294","inReplyTo":"7vehbii6un.fsf@alter.siamese.dyndns.org","subject":"[RFC/PATCHv3] submodule update: allow custom update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-02T10:12:54Z","receivedAt":"2013-07-02T10:12:54Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Users can set submodule.$name.update to '!command' which will cause\n'command' to be run instead of checkout/merge/rebase.  This allows the\nuser some finer grained control over how the update is done. The primary\nmotivation for this was interoperability with stgit however being able\nto intercept the submodule update process may prove useful for\nintegrating or extending other tools.\n\nSigned-off-by: Chris Packham <judge.packham@gmail.com>\n---\nv3 updated as per Junio's review.\n\nStill needs tests. Any suggestions? I've been manually testing by setting\nsubmodule.$name.update to '!echo'. I haven't looked to see if there are\nexisting 'submodule update' tests yet.\n\n Documentation/git-submodule.txt | 5 ++++-\n git-submodule.sh                | 6 ++++++\n 2 files changed, 10 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex e576713..0befc20 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -159,7 +159,9 @@ update::\n \tThis will make the submodules HEAD be detached unless `--rebase` or\n \t`--merge` is specified or the key `submodule.$name.update` is set to\n \t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n-\t`--checkout`.\n+\t`--checkout`. Setting the key `submodule.$name.update` to `!command`\n+\twill cause `command` to be run. `command` can be any arbitrary shell\n+\tcommand that takes a single argument, namely the sha1 to update to.\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@@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n `git checkout --force` if appropriate), even if the commit specified in the\n index of the containing repository already matches the commit checked out in\n the submodule.\n++\n \n summary::\n \tShow commit summary between the given commit (defaults to HEAD) and\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex eb58c8e..a7c2375 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n \t\t\t\tmust_die_on_failure=yes\n \t\t\t\t;;\n+\t\t\t!*)\n+\t\t\t\tcommand=\"${update_module#!}\"\n+\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n+\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n+\t\t\t\tmust_die_on_failure=yes\n+\t\t\t\t;;\n \t\t\t*)\n \t\t\t\tcommand=\"git checkout $subforce -q\"\n \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n-- \n1.8.3.1.644.gfaf2af3\n"},{"id":"222374","messageId":"51D3064C.80901@web.de","threadId":"34294","inReplyTo":"1372759974-19765-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-07-02T16:56:44Z","receivedAt":"2013-07-02T16:56:44Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.07.2013 12:12, schrieb Chris Packham:\n> Users can set submodule.$name.update to '!command' which will cause\n> 'command' to be run instead of checkout/merge/rebase.  This allows the\n> user some finer grained control over how the update is done. The primary\n> motivation for this was interoperability with stgit however being able\n> to intercept the submodule update process may prove useful for\n> integrating or extending other tools.\n> \n> Signed-off-by: Chris Packham <judge.packham@gmail.com>\n> ---\n> v3 updated as per Junio's review.\n\nThanks, a few comments below.\n\n> Still needs tests. Any suggestions? I've been manually testing by setting\n> submodule.$name.update to '!echo'. I haven't looked to see if there are\n> existing 'submodule update' tests yet.\n\nt7406-submodule-update.sh should be the right place.\n\n>  Documentation/git-submodule.txt | 5 ++++-\n>  git-submodule.sh                | 6 ++++++\n>  2 files changed, 10 insertions(+), 1 deletion(-)\n> \n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index e576713..0befc20 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -159,7 +159,9 @@ update::\n>  \tThis will make the submodules HEAD be detached unless `--rebase` or\n>  \t`--merge` is specified or the key `submodule.$name.update` is set to\n>  \t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n> -\t`--checkout`.\n> +\t`--checkout`. Setting the key `submodule.$name.update` to `!command`\n> +\twill cause `command` to be run. `command` can be any arbitrary shell\n> +\tcommand that takes a single argument, namely the sha1 to update to.\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> @@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n>  `git checkout --force` if appropriate), even if the commit specified in the\n>  index of the containing repository already matches the commit checked out in\n>  the submodule.\n> ++\n>  \n>  summary::\n>  \tShow commit summary between the given commit (defaults to HEAD) and\n\nI'm not sure this change is necessary ;-)\n\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index eb58c8e..a7c2375 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n>  \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n>  \t\t\t\tmust_die_on_failure=yes\n>  \t\t\t\t;;\n> +\t\t\t!*)\n> +\t\t\t\tcommand=\"${update_module#!}\"\n> +\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n\nHmm, \"Unable to exec\" does not quite cut it, as the command was executed\nbut returned an error, right? Maybe something like this:\n\n   Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\n\n> +\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n> +\t\t\t\tmust_die_on_failure=yes\n> +\t\t\t\t;;\n>  \t\t\t*)\n>  \t\t\t\tcommand=\"git checkout $subforce -q\"\n>  \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n> \n"},{"id":"222422","messageId":"CAFOYHZC1xMt2eqaNm0vtLVJ3X2TNjRxa3sEjBPmHVeHrQmSc4A@mail.gmail.com","threadId":"34294","inReplyTo":"51D3064C.80901@web.de","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-02T23:26:13Z","receivedAt":"2013-07-02T23:26:13Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 02.07.2013 12:12, schrieb Chris Packham:\n>> --- a/Documentation/git-submodule.txt\n>> +++ b/Documentation/git-submodule.txt\n>> @@ -159,7 +159,9 @@ update::\n>>       This will make the submodules HEAD be detached unless `--rebase` or\n>>       `--merge` is specified or the key `submodule.$name.update` is set to\n>>       `rebase`, `merge` or `none`. `none` can be overridden by specifying\n>> -     `--checkout`.\n>> +     `--checkout`. Setting the key `submodule.$name.update` to `!command`\n>> +     will cause `command` to be run. `command` can be any arbitrary shell\n>> +     command that takes a single argument, namely the sha1 to update to.\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>> @@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n>>  `git checkout --force` if appropriate), even if the commit specified in the\n>>  index of the containing repository already matches the commit checked out in\n>>  the submodule.\n>> ++\n>>\n>>  summary::\n>>       Show commit summary between the given commit (defaults to HEAD) and\n>\n> I'm not sure this change is necessary ;-)\n>\n\nNot necessary because it should be documented in\nDocumentation/config.txt instead, or not necessary because it's a\nniche feature that doesn't need to be advertised?\n\n>> diff --git a/git-submodule.sh b/git-submodule.sh\n>> index eb58c8e..a7c2375 100755\n>> --- a/git-submodule.sh\n>> +++ b/git-submodule.sh\n>> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n>>                               say_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n>>                               must_die_on_failure=yes\n>>                               ;;\n>> +                     !*)\n>> +                             command=\"${update_module#!}\"\n>> +                             die_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n>\n> Hmm, \"Unable to exec\" does not quite cut it, as the command was executed\n> but returned an error, right? Maybe something like this:\n>\n>    Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\n>\n\nWill include in v4 once I write some tests.\n"},{"id":"222428","messageId":"51D3CAE8.50509@web.de","threadId":"34294","inReplyTo":"CAFOYHZC1xMt2eqaNm0vtLVJ3X2TNjRxa3sEjBPmHVeHrQmSc4A@mail.gmail.com","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-07-03T06:55:36Z","receivedAt":"2013-07-03T06:55:36Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.07.2013 01:26, schrieb Chris Packham:\n> On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>> Am 02.07.2013 12:12, schrieb Chris Packham:\n>>> --- a/Documentation/git-submodule.txt\n>>> +++ b/Documentation/git-submodule.txt\n>>> @@ -159,7 +159,9 @@ update::\n>>>       This will make the submodules HEAD be detached unless `--rebase` or\n>>>       `--merge` is specified or the key `submodule.$name.update` is set to\n>>>       `rebase`, `merge` or `none`. `none` can be overridden by specifying\n>>> -     `--checkout`.\n>>> +     `--checkout`. Setting the key `submodule.$name.update` to `!command`\n>>> +     will cause `command` to be run. `command` can be any arbitrary shell\n>>> +     command that takes a single argument, namely the sha1 to update to.\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\nThe above hunk is perfectly fine ...\n\n>>> @@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n>>>  `git checkout --force` if appropriate), even if the commit specified in the\n>>>  index of the containing repository already matches the commit checked out in\n>>>  the submodule.\n>>> ++\n>>>\n>>>  summary::\n>>>       Show commit summary between the given commit (defaults to HEAD) and\n\n... but I don't understand the extra '+'-line added here.\n\n>> I'm not sure this change is necessary ;-)\n> \n> Not necessary because it should be documented in\n> Documentation/config.txt instead, or not necessary because it's a\n> niche feature that doesn't need to be advertised?\n\nSorry for the confusion, I should have been more specific here.\n\n>>> diff --git a/git-submodule.sh b/git-submodule.sh\n>>> index eb58c8e..a7c2375 100755\n>>> --- a/git-submodule.sh\n>>> +++ b/git-submodule.sh\n>>> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n>>>                               say_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n>>>                               must_die_on_failure=yes\n>>>                               ;;\n>>> +                     !*)\n>>> +                             command=\"${update_module#!}\"\n>>> +                             die_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n>>\n>> Hmm, \"Unable to exec\" does not quite cut it, as the command was executed\n>> but returned an error, right? Maybe something like this:\n>>\n>>    Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\n>>\n> \n> Will include in v4 once I write some tests.\n\nThanks.\n"},{"id":"222434","messageId":"51D3D8CD.5090804@gmail.com","threadId":"34294","inReplyTo":"51D3CAE8.50509@web.de","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-03T07:54:53Z","receivedAt":"2013-07-03T07:54:53Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 03/07/13 18:55, Jens Lehmann wrote:\n> Am 03.07.2013 01:26, schrieb Chris Packham:\n>> On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>>> Am 02.07.2013 12:12, schrieb Chris Packham:\n>>>> --- a/Documentation/git-submodule.txt\n>>>> +++ b/Documentation/git-submodule.txt\n>>>> @@ -159,7 +159,9 @@ update::\n>>>>       This will make the submodules HEAD be detached unless `--rebase` or\n>>>>       `--merge` is specified or the key `submodule.$name.update` is set to\n>>>>       `rebase`, `merge` or `none`. `none` can be overridden by specifying\n>>>> -     `--checkout`.\n>>>> +     `--checkout`. Setting the key `submodule.$name.update` to `!command`\n>>>> +     will cause `command` to be run. `command` can be any arbitrary shell\n>>>> +     command that takes a single argument, namely the sha1 to update to.\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> \n> The above hunk is perfectly fine ...\n> \n>>>> @@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using\n>>>>  `git checkout --force` if appropriate), even if the commit specified in the\n>>>>  index of the containing repository already matches the commit checked out in\n>>>>  the submodule.\n>>>> ++\n>>>>\n>>>>  summary::\n>>>>       Show commit summary between the given commit (defaults to HEAD) and\n> \n> ... but I don't understand the extra '+'-line added here.\n> \n>>> I'm not sure this change is necessary ;-)\n>>\n>> Not necessary because it should be documented in\n>> Documentation/config.txt instead, or not necessary because it's a\n>> niche feature that doesn't need to be advertised?\n> \n> Sorry for the confusion, I should have been more specific here.\n> \n\nAh that makes sense. It's left over from the '--exec' option in v1. Will\nbe cleaned up in v4.\n\nOn a related note should I be updating Documentation/config.txt as well?\nEven if it's a statement that this feature exists refer to\ngit-submodule(1) for details.\n\n>>>> diff --git a/git-submodule.sh b/git-submodule.sh\n>>>> index eb58c8e..a7c2375 100755\n>>>> --- a/git-submodule.sh\n>>>> +++ b/git-submodule.sh\n>>>> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n>>>>                               say_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n>>>>                               must_die_on_failure=yes\n>>>>                               ;;\n>>>> +                     !*)\n>>>> +                             command=\"${update_module#!}\"\n>>>> +                             die_msg=\"$(eval_gettext \"Unable to exec '\\$command \\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n>>>\n>>> Hmm, \"Unable to exec\" does not quite cut it, as the command was executed\n>>> but returned an error, right? Maybe something like this:\n>>>\n>>>    Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\n>>>\n>>\n>> Will include in v4 once I write some tests.\n> \n> Thanks.\n> \n"},{"id":"222441","messageId":"51D3E5BA.1090408@gmail.com","threadId":"34294","inReplyTo":"51D3D8CD.5090804@gmail.com","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-03T08:50:02Z","receivedAt":"2013-07-03T08:50:02Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 03/07/13 19:54, Chris Packham wrote:\n> On a related note should I be updating Documentation/config.txt as well?\n> Even if it's a statement that this feature exists refer to\n> git-submodule(1) for details.\n> \n\nAnswering my own question. While 'update' is mentioned it's possible\nvalues are not.\n"},{"id":"222445","messageId":"1372842122-15568-1-git-send-email-judge.packham@gmail.com","threadId":"34294","inReplyTo":"51D3064C.80901@web.de","subject":"[RFC/PATCHv4] submodule update: allow custom update command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2013-07-03T09:02:02Z","receivedAt":"2013-07-03T09:02:02Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Users can set submodule.$name.update to '!command' which will cause\n'command' to be run instead of checkout/merge/rebase.  This allows the\nuser some finer grained control over how the update is done. The primary\nmotivation for this was interoperability with stgit however being able\nto intercept the submodule update process may prove useful for\nintegrating with or extensions to other tools.\n\nSigned-off-by: Chris Packham <judge.packham@gmail.com>\n---\nv4 adds a couple of simple tests - an equivalent of update=checkout and a test\nto make sure we detect a failure reported by the update command.\n\n Documentation/git-submodule.txt |  4 +++-\n git-submodule.sh                |  6 ++++++\n t/t7406-submodule-update.sh     | 29 +++++++++++++++++++++++++++++\n 3 files changed, 38 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex e576713..2f18f7d 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -159,7 +159,9 @@ update::\n \tThis will make the submodules HEAD be detached unless `--rebase` or\n \t`--merge` is specified or the key `submodule.$name.update` is set to\n \t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n-\t`--checkout`.\n+\t`--checkout`. Setting the key `submodule.$name.update` to `!command`\n+\twill cause `command` to be run. `command` can be any arbitrary shell\n+\tcommand that takes a single argument, namely the sha1 to update to.\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\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex eb58c8e..e7579f0 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n \t\t\t\tmust_die_on_failure=yes\n \t\t\t\t;;\n+\t\t\t!*)\n+\t\t\t\tcommand=\"${update_module#!}\"\n+\t\t\t\tdie_msg=\"$(eval_gettext \"Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\")\"\n+\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n+\t\t\t\tmust_die_on_failure=yes\n+\t\t\t\t;;\n \t\t\t*)\n \t\t\t\tcommand=\"git checkout $subforce -q\"\n \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex a4ffea0..48d1279 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -279,6 +279,35 @@ test_expect_success 'submodule update - checkout in .git/config' '\n \t)\n '\n \n+test_expect_success 'submodule update - command in .git/config' '\n+\t(cd super &&\n+\t git config submodule.submodule.update \"!git checkout\"\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 update - command in .git/config catches failure' '\n+\t(cd super &&\n+\t git config submodule.submodule.update \"!false\"\n+\t) &&\n+\t(cd super/submodule &&\n+\t  git reset --hard HEAD^\n+\t) &&\n+\t(cd super &&\n+\t test_must_fail git submodule update submodule\n+\t)\n+'\n+\n test_expect_success 'submodule init picks up rebase' '\n \t(cd super &&\n \t git config -f .gitmodules submodule.rebasing.update rebase &&\n-- \n1.8.3.1.644.ge86575b\n"},{"id":"222469","messageId":"7v8v1nh8o8.fsf@alter.siamese.dyndns.org","threadId":"34294","inReplyTo":"51D3E5BA.1090408@gmail.com","subject":"Re: [RFC/PATCHv3] submodule update: allow custom update command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-03T17:09:43Z","receivedAt":"2013-07-03T17:09:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> On 03/07/13 19:54, Chris Packham wrote:\n>> On a related note should I be updating Documentation/config.txt as well?\n>> Even if it's a statement that this feature exists refer to\n>> git-submodule(1) for details.\n>> \n>\n> Answering my own question. While 'update' is mentioned it's possible\n> values are not.\n\nYeah, I think it is good as-is.\n\nThe entry in config.txt points at git-submodule(1) and your patch\nupdates the latter by adding another possible value, so the values\nare discoverable; we do not have to maintain two separate lists and\nkeep them in sync that way.\n"},{"id":"222470","messageId":"7v4ncbh8ap.fsf@alter.siamese.dyndns.org","threadId":"34294","inReplyTo":"1372842122-15568-1-git-send-email-judge.packham@gmail.com","subject":"Re: [RFC/PATCHv4] submodule update: allow custom update command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-03T17:17:50Z","receivedAt":"2013-07-03T17:17:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham <judge.packham@gmail.com> writes:\n\n> Users can set submodule.$name.update to '!command' which will cause\n> 'command' to be run instead of checkout/merge/rebase.  This allows the\n> user some finer grained control over how the update is done. The primary\n> motivation for this was interoperability with stgit however being able\n> to intercept the submodule update process may prove useful for\n> integrating with or extensions to other tools.\n>\n> Signed-off-by: Chris Packham <judge.packham@gmail.com>\n> ---\n> v4 adds a couple of simple tests - an equivalent of update=checkout and a test\n> to make sure we detect a failure reported by the update command.\n\nI think this can drop RFC/ now ;-)\n\nWill replace what was queued and merge to 'next' unless I hear\notherwise within a few days.\n\nThanks.\n\n>\n>  Documentation/git-submodule.txt |  4 +++-\n>  git-submodule.sh                |  6 ++++++\n>  t/t7406-submodule-update.sh     | 29 +++++++++++++++++++++++++++++\n>  3 files changed, 38 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index e576713..2f18f7d 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -159,7 +159,9 @@ update::\n>  \tThis will make the submodules HEAD be detached unless `--rebase` or\n>  \t`--merge` is specified or the key `submodule.$name.update` is set to\n>  \t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n> -\t`--checkout`.\n> +\t`--checkout`. Setting the key `submodule.$name.update` to `!command`\n> +\twill cause `command` to be run. `command` can be any arbitrary shell\n> +\tcommand that takes a single argument, namely the sha1 to update to.\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> diff --git a/git-submodule.sh b/git-submodule.sh\n> index eb58c8e..e7579f0 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?\")\"\n>  \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': merged in '\\$sha1'\")\"\n>  \t\t\t\tmust_die_on_failure=yes\n>  \t\t\t\t;;\n> +\t\t\t!*)\n> +\t\t\t\tcommand=\"${update_module#!}\"\n> +\t\t\t\tdie_msg=\"$(eval_gettext \"Execution of '\\$command \\$sha1' failed in submodule  path '\\$prefix\\$sm_path'\")\"\n> +\t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$prefix\\$sm_path': '\\$command \\$sha1'\")\"\n> +\t\t\t\tmust_die_on_failure=yes\n> +\t\t\t\t;;\n>  \t\t\t*)\n>  \t\t\t\tcommand=\"git checkout $subforce -q\"\n>  \t\t\t\tdie_msg=\"$(eval_gettext \"Unable to checkout '\\$sha1' in submodule path '\\$prefix\\$sm_path'\")\"\n> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> index a4ffea0..48d1279 100755\n> --- a/t/t7406-submodule-update.sh\n> +++ b/t/t7406-submodule-update.sh\n> @@ -279,6 +279,35 @@ test_expect_success 'submodule update - checkout in .git/config' '\n>  \t)\n>  '\n>  \n> +test_expect_success 'submodule update - command in .git/config' '\n> +\t(cd super &&\n> +\t git config submodule.submodule.update \"!git checkout\"\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 update - command in .git/config catches failure' '\n> +\t(cd super &&\n> +\t git config submodule.submodule.update \"!false\"\n> +\t) &&\n> +\t(cd super/submodule &&\n> +\t  git reset --hard HEAD^\n> +\t) &&\n> +\t(cd super &&\n> +\t test_must_fail git submodule update submodule\n> +\t)\n> +'\n> +\n>  test_expect_success 'submodule init picks up rebase' '\n>  \t(cd super &&\n>  \t git config -f .gitmodules submodule.rebasing.update rebase &&\n"}]}