On 01/07/13 03:30, Jens Lehmann wrote: > Am 29.06.2013 11:11, schrieb Chris Packham: >> On 28/06/13 22:42, Fredrik Gustafsson wrote: >>> 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. > > Wouldn't a "stgit submodule update" (which would do the Right Thing for > submodules initialized with stgit by maybe just using the pull & foreach > logic you described) be a better UI for solving your problem? Yeah I guess so. I was hoping to stay away from an stgit specific solution but I'm not hearing any other voices looking for such flexibility. >> 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. > > Hmm, if we go that route, why not do the same we do for aliases? If > the submodule.*.update setting is prefixed with a '!', we just execute > the shell command following. This would give everyone the freedom to > do arbitrary stuff if the current none, checkout, merge & rebase won't > do the trick without having to add another config option. > Make sense. I'll give it a go. -- 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