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? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iveqy@xxxxxxxxx -- 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