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

[Chris Packham <judge.packham@gmail.com>]

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 <judge.packham@gmail.com>
>> --
>> 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.