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. > And from my point of view, "rebind" (or "autorebind") would be more > appropriate name than "update" Feel free to fix up my patch with whatever the community finds most appropriate. Personally, I still like "update" better because it determines what "happens" on a git submodule update, but I'm not religious about this. > (and I would probably set it to "never"). That's perfectly ok. So will I, in most of my repos. But there are cases (e.g. in the workflows at $dayjob) where this feature will be very valuable. ...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