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