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