Hi, On Tue, 19 May 2009, Johan Herland wrote: > On Tuesday 19 May 2009, Junio C Hamano wrote: > > Johan Herland <johan@xxxxxxxxxxx> writes: > > > After some thinking, I don't like my original name > > > submodule.<name>.resolve, since ".resolve" sounds more like a merge > > > strategy or conflict resolution method, than a "how to deal with > > > submodule update" choice. I propose submodule.<name>.update instead. > > > > Sounds like a plan, even though I do not necessarily agree with the > > idea of automatically rebinding what is at the submodule path every > > time you update the toplevel project tree. > > I agree that in many workflows this does not make sense, but I believe > that (as with 'git submodule update --rebase') there are some cases > where it does make sense, and I see no reason to support one, but not > the other. We have a _lot_ of obscure things that are not supported by core Git, but are _very_ easy to add as _tiny_ add-on scripts by the user, without the need for "official" feature support. Just like this one, Dscho -- 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