Re: git submodule update --merge (Was: What's cooking in git.git (May 2009, #02; Sun, 17))

[Peter Hutterer <peter.hutterer@who-t.net>]

On Mon, May 25, 2009 at 01:59:37PM +0200, Johan Herland wrote:
> On Tuesday 19 May 2009, Johan Herland wrote:
> > On Tuesday 19 May 2009, Johannes Schindelin wrote:
> > > On Tue, 19 May 2009, Johan Herland wrote:
> > > > 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.
> >
> > But if there are developers downstream whose work is based on your
> > submodule branch, the rebase will disrupt _their_ work, in the same
> > way that rebasing any other public branch would disrupt people's
> > work.
> >
> > > In contrast, if you merge, you will have a different state from the
> > > upstream _forever_.  Even if your stuff gets included.
> >
> > Correct, but there are cases where reconciliation with the upstream
> > repo is less important than not disrupting downstream developers (see
> > below).
> >
> > > Needless to say, I do not see much use for the latter case, but
> > > tons for the former.
> >
> > I fully agree that for a regular downstream (or "leaf") developer,
> > there is not much use for git submodule rebase --merge.
> >
> > But not all developers fit nicely into your scenario above.
> > 
> > [Workflow description in which "git submodule update --merge" would
> >  be a helpful addition]
> >
> > I understand that the above scenario is not common in the free
> > software world, but I believe it is much more common in an
> > enterprise/company setting. Therefore, the support of such workflows
> > is important to companies that are currently considering (or have
> > already chosen) Git. I believe there is value in supporting such
> > workflows, especially when doing so is as straightforward as my patch
> > shows.
> 
> I haven't received any replies to my attempt to describe the context in 
> which "git submodule update --merge" is useful. A hint as to whether my 
> argument is valid, or just crap, would be nice.
> 
> In any case, even if we don't include "git submodule update --merge", 
> could we _please_ consider changing the associated config variable from
> 
>   submodule.<name>.rebase = true/false (false if unset)
> 
> to something like
> 
>   submodule.<name>.update = checkout/rebase (checkout if unset)
> 
> or (Junio's suggestion)
> 
>   submodule.<name>.rebind = never/rebase (never if unset)
> 
> so that we at least have the _option_ of adding other alternatives in 
> the future?

I can't really chime in on the merge debate since it's not part of my
workflow, but I definitely support the above. Even if we never add any
options other than checkout/rebase, it's still better than the prospect of
having possibly conflicting boolean settings in the future.

Cheers,
  Peter