Re: What's cooking in git.git (May 2009, #02; Sun, 17)

[Johan Herland <johan@herland.net>]

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@herland.net>
www.herland.net