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

From: Chris Packham <judge.packham@gmail.com>
Date: Jun 29, 2013, 09:11 UTC
Message-ID: <51CEA4B2.1090008@gmail.com>
In-Reply-To: <20130628104243.GD27497@paksenarrion.iveqy.com>

On 28/06/13 22:42, Fredrik Gustafsson wrote:

Show 37 quoted lines

> 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.