On Monday 18 May 2009, Markus Heidelberg wrote: > Johan Herland, 18.05.2009: > > On Sunday 17 May 2009, Junio C Hamano wrote: > > > [Will merge to "master" soon] > > > > > > * ph/submodule-rebase (Fri Apr 24 09:06:38 2009 +1000) 1 commit > > > + git-submodule: add support for --rebase. > > > > [..] > > > > Now, my question should not stop this feature from going into 'master', > > except for the fact that if we also want to support merge, we should > > rename the associated config variable: > > > > Instead of > > > > submodule.<name>.rebase = true/false (false if unset) > > > > we should have something like > > > > submodule.<name>.resolve = checkout/rebase/merge (checkout if unset) > > At least this would be inconsistent with options like > branch.<name>.merge and branch.<name>.rebase No. We cannot "reuse" the branch.<name>.merge/rebase semantics in this case: branch.<name>.merge takes a remote branch name to merge with, while submodule.<name>.merge needs no such name (the merge is well-specified without that extra name: the new submodule commit is merged into the submodule's current branch). Thus, submodule.<name>.merge is reduced to a simple bool indicating whether or not we should merge. At this point, however, it is not only inconsistent with branch.<name>.merge, it also directly conflicts with submodule.<name>.rebase (they cannot both be "true" simultaneously). They should therefore be collapsed into one tri-state config variable set to either 'rebase', 'merge' or 'false'/unset (which triggers the default 'checkout' behaviour). This is pretty much what I propose above. 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. ...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