Hi, On Tue, 19 May 2009, Johan Herland wrote: > 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)? No, because -- as I said myself already a couple of times -- I can see this supporting a common workflow. > I still don't see any reason why one should be added (--rebase), and not > the other (--merge). When you rebase, you see your personal stuff (i.e. stuff that you do not want to submit, or not in its current form, or that you submitted and it waits for inclusion) on top of things right away. In contrast, if you merge, you will have a different state from the upstream _forever_. Even if your stuff gets included. Needless to say, I do not see much use for the latter case, but tons for the former. > 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")... I will not bother to comment on this. Ciao, 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