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

[Johan Herland <johan@herland.net>]

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?


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net