Re: [RFC/PATCH] submodule: add 'exec' option to submodule update

[Jens Lehmann <Jens.Lehmann@web.de>]

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.