[RFC/PATCH] submodule: add 'exec' option to submodule update
This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the submodule update process may prove useful for integrating or extending other tools. Signed-off-by: Chris Packham -- Hi, At $dayjob we have a number of users that are accustomed to using stgit. Stgit doesn't play nicely with git rebase which would be the logical setting for submodule.*.update for our usage. Instead we need to run 'stg rebase --merged' on those submodules that have been initialised with stgit. Our current solution is an in-house script which is a poor substitute for git submodule update. I'd much rather replace our script with git submodule update but we do have a requirement to keep stgit for the foreseeable future. Rather than narrowing in on stgit it seems logical to allow an arbitrary update command to be executed. --- Documentation/git-submodule.txt | 8 +++- git-submodule.sh| 22 +- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index e576713..a0d8b89 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -16,7 +16,7 @@ SYNOPSIS 'git submodule' [--quiet] deinit [-f|--force] [--] ... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] - [--merge] [--recursive] [--] [...] + [--merge] [--recursive] [--exec ] [--] [...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ] [commit] [--] [...] 'git submodule' [--quiet] foreach [--recursive] @@ -172,6 +172,12 @@ If `--force` is specified, the submodule will be checked out (using `git checkout --force` if appropriate), even if the commit specified in the index of the containing repository already matches the commit checked out in the submodule. ++ +If `--exec` is specified the next argument is an arbitrary shell command that +can be used to gain finer control over how the update is done or integrate with +external tools. The command should take one argument namely the sha1 of the +commit to update to. The config variable `submodule.$name.update` can be set +to `exec` along with `submodule.$name.update.command`. summary:: Show commit summary between the given commit (defaults to HEAD) and diff --git a/git-submodule.sh b/git-submodule.sh index eb58c8e..44631c8 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -9,7 +9,7 @@ USAGE="[--quiet] add [-b ] [-f|--force] [--name ] [--reference ...] or: $dashless [--quiet] init [--] [...] or: $dashless [--quiet] deinit [-f|--force] [--] ... - or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...] + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--exec ] [--] [...] or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...] or: $dashless [--quiet] foreach [--recursive] or: $dashless [--quiet] sync [--recursive] [--] [...]" @@ -32,6 +32,7 @@ nofetch= update= prefix= custom_name= +update_exec_command= # The function takes at most 2 arguments. The first argument is the # URL that navigates to the submodule origin repo. When relative, this URL @@ -677,6 +678,12 @@ cmd_update() --checkout) update="checkout" ;; + --exec) + case "$2" in '') usage ;; esac + update="exec" + update_exec_command="$2" + shift + ;; --) shift break @@ -718,6 +725,11 @@ cmd_update() update_module=$(git config submodule."$name".update) fi + if test -z "$update_exec_command" + then + exec_command=$(git config submodule."$name".update.command) + fi + if test "$update_module" = "none" then echo "Skipping submodule '$prefix$sm_path'" @@ -799,6 +811,14 @@ Maybe you want to use 'update --init'?")" say_msg="$(eval_gettext "Submodule path '\$prefix\$sm_path': merged in '\$sha1'")" must_die_on_failure=yes ;; + exec) + test -n "$exec_command" || \ + die "$(eval_gettext "Unable to update '\$prefix\$sm_path' exec command not specified")" + command="$exec_command" + die_msg="$(eval_
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Am 28.06.2013 11:53, schrieb Chris Packham:
> This allows the user some finer grained control over how the update is
> done. The primary motivation for this was interoperability with stgit
> however being able to intercept the submodule update process may prove
> useful for integrating or extending other tools.
>
> Signed-off-by: Chris Packham
> --
> Hi,
>
> At $dayjob we have a number of users that are accustomed to using stgit.
> Stgit doesn't play nicely with git rebase which would be the logical
> setting for submodule.*.update for our usage. Instead we need to run
> 'stg rebase --merged' on those submodules that have been initialised
> with stgit.
>
> Our current solution is an in-house script which is a poor substitute
> for git submodule update. I'd much rather replace our script with git
> submodule update but we do have a requirement to keep stgit for the
> foreseeable future. Rather than narrowing in on stgit it seems logical
> to allow an arbitrary update command to be executed.
Hhmmm...
Can't the same be accomplished with
git submodule foreach 'your-update-script $sha1'
Am I missing something?
Stefan
--
/dev/random says: Preserve nature... pickle a squirrel.
python -c "print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Hi, On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote: > This allows the user some finer grained control over how the update is > done. The primary motivation for this was interoperability with stgit > however being able to intercept the submodule update process may prove > useful for integrating or extending other tools. > > Signed-off-by: Chris Packham > -- > Hi, > > At $dayjob we have a number of users that are accustomed to using stgit. > Stgit doesn't play nicely with git rebase which would be the logical > setting for submodule.*.update for our usage. Instead we need to run > 'stg rebase --merged' on those submodules that have been initialised > with stgit. > > Our current solution is an in-house script which is a poor substitute > for git submodule update. I'd much rather replace our script with git > submodule update but we do have a requirement to keep stgit for the > foreseeable future. Rather than narrowing in on stgit it seems logical > to allow an arbitrary update command to be executed. > --- > Documentation/git-submodule.txt | 8 +++- > git-submodule.sh| 22 +- > 2 files changed, 28 insertions(+), 2 deletions(-) > technically it looks fine to me (except for the lack of tests) but I'm not sure I follow the use case. In your case, you want to run a script to determinate if that certain submodule should use merge or rebase depending on "whatever". And this can't be done with git submodule foreach because you want to know the sha1 to update to. Have I understood you correctly? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
On 28/06/13 22:42, Fredrik Gustafsson wrote: > Hi, > > On Fri, Jun 28, 2013 at 09:53:10PM +1200, Chris Packham wrote: >> This allows the user some finer grained control over how the update is >> done. The primary motivation for this was interoperability with stgit >> however being able to intercept the submodule update process may prove >> useful for integrating or extending other tools. >> >> Signed-off-by: Chris Packham >> -- >> Hi, >> >> At $dayjob we have a number of users that are accustomed to using stgit. >> Stgit doesn't play nicely with git rebase which would be the logical >> setting for submodule.*.update for our usage. Instead we need to run >> 'stg rebase --merged' on those submodules that have been initialised >> with stgit. >> >> Our current solution is an in-house script which is a poor substitute >> for git submodule update. I'd much rather replace our script with git >> submodule update but we do have a requirement to keep stgit for the >> foreseeable future. Rather than narrowing in on stgit it seems logical >> to allow an arbitrary update command to be executed. >> --- >> Documentation/git-submodule.txt | 8 +++- >> git-submodule.sh| 22 +- >> 2 files changed, 28 insertions(+), 2 deletions(-) >> > > technically it looks fine to me (except for the lack of tests) but I'm > not sure I follow the use case. > > In your case, you want to run a script to determinate if that certain > submodule should use merge or rebase depending on "whatever". And this > can't be done with git submodule foreach because you want to know the > sha1 to update to. Have I understood you correctly? > Correct. We tend to have submodules that are just normal detached heads which we don't usually touch and others that are actively developed where we would use submodule.x.update=rebase (I personally do) but some developers want to use stgit on those repositories. Another approach could be to do a 'git pull --no-recurse-submodule' then use 'git submodule foreach script-that-does-the-rebase'. The benefit of the patch I sent is that it can be setup using the config variables[1] and updated the normal way along with the detached HEADs and those using plain git branches. There may be other use-cases for integration with other tools as well (e.g. something that updates a review tool when commits get rebased). -- [1] I'm not crazy about the name of submodule.*.update.command but I couldn't think of a better one. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Am 29.06.2013 11:11, schrieb Chris Packham: > On 28/06/13 22:42, Fredrik Gustafsson wrote: >> technically it looks fine to me (except for the lack of tests) but I'm >> not sure I follow the use case. >> >> In your case, you want to run a script to determinate if that certain >> submodule should use merge or rebase depending on "whatever". And this >> can't be done with git submodule foreach because you want to know the >> sha1 to update to. Have I understood you correctly? > > Correct. We tend to have submodules that are just normal detached heads > which we don't usually touch and others that are actively developed > where we would use submodule.x.update=rebase (I personally do) but some > developers want to use stgit on those repositories. > > Another approach could be to do a 'git pull --no-recurse-submodule' then > use 'git submodule foreach script-that-does-the-rebase'. The benefit of > the patch I sent is that it can be setup using the config variables[1] > and updated the normal way along with the detached HEADs and those using > plain git branches. Wouldn't a "stgit submodule update" (which would do the Right Thing for submodules initialized with stgit by maybe just using the pull & foreach logic you described) be a better UI for solving your problem? > There may be other use-cases for integration with other tools as well > (e.g. something that updates a review tool when commits get rebased). > > -- > [1] I'm not crazy about the name of submodule.*.update.command but I > couldn't think of a better one. Hmm, if we go that route, why not do the same we do for aliases? If the submodule.*.update setting is prefixed with a '!', we just execute the shell command following. This would give everyone the freedom to do arbitrary stuff if the current none, checkout, merge & rebase won't do the trick without having to add another config option. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
On 01/07/13 03:30, Jens Lehmann wrote: > Am 29.06.2013 11:11, schrieb Chris Packham: >> On 28/06/13 22:42, Fredrik Gustafsson wrote: >>> technically it looks fine to me (except for the lack of tests) but I'm >>> not sure I follow the use case. >>> >>> In your case, you want to run a script to determinate if that certain >>> submodule should use merge or rebase depending on "whatever". And this >>> can't be done with git submodule foreach because you want to know the >>> sha1 to update to. Have I understood you correctly? >> >> Correct. We tend to have submodules that are just normal detached heads >> which we don't usually touch and others that are actively developed >> where we would use submodule.x.update=rebase (I personally do) but some >> developers want to use stgit on those repositories. >> >> Another approach could be to do a 'git pull --no-recurse-submodule' then >> use 'git submodule foreach script-that-does-the-rebase'. The benefit of >> the patch I sent is that it can be setup using the config variables[1] >> and updated the normal way along with the detached HEADs and those using >> plain git branches. > > Wouldn't a "stgit submodule update" (which would do the Right Thing for > submodules initialized with stgit by maybe just using the pull & foreach > logic you described) be a better UI for solving your problem? Yeah I guess so. I was hoping to stay away from an stgit specific solution but I'm not hearing any other voices looking for such flexibility. >> There may be other use-cases for integration with other tools as well >> (e.g. something that updates a review tool when commits get rebased). >> >> -- >> [1] I'm not crazy about the name of submodule.*.update.command but I >> couldn't think of a better one. > > Hmm, if we go that route, why not do the same we do for aliases? If > the submodule.*.update setting is prefixed with a '!', we just execute > the shell command following. This would give everyone the freedom to > do arbitrary stuff if the current none, checkout, merge & rebase won't > do the trick without having to add another config option. > Make sense. I'll give it a go. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
