On Tuesday 19 May 2009, Johannes Schindelin wrote: > 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 Does that mean you're also opposed to 'git submodule update --rebase' (which is already in 'next', and is even Signed-off-by yourself)? I still don't see any reason why one should be added (--rebase), and not the other (--merge). Dropping both would at least be consistent from core Git's POV, but following that thread, we should probably also drop "git pull" (which is just a simple wrapper around "git fetch" and "git merge"), and maybe also "git clone" (which can easily be scripted, using "git init", "git remote", "git fetch" and "git branch")... ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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