On 28/06/13 22:42, Fredrik Gustafsson wrote:
> 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.pack...@gmail.com>
>> 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
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).
 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