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@xxxxxxxxx> >> -- >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html