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

> 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.