On Fri, Dec 17, 2010 at 12:52:07PM -0800, Junio C Hamano wrote: > >> > We have color.diff.branch coming soon (I think it is in 'next' now). > > > > The "correct" thing to do from a topic branch standpoint is to submit > > this patch without it as its own topic, submit a patch with just > > color.diff.branch on top of the other topic, and then the merge > > resolution will include both sets. > > Perhaps, if we had color.diff.branch ;-). Urgh. Color.status.branch is what I meant all along. > > > > But I'll let Junio decide how meticulous about history he wants to be. > > Well, in this case, probably the right thing to do is to ignore this > addition to completion as the lowest priority item for now, wait for other > changes that add or modify the set of configuration variables to land on > 'master', and then resubmit a single patch. Sure, that is reasonable to me. > Yes, merge is wonderful and easy, but it is merely a tool to help > coordination between developers (the ones who add code to understand new > variables, the others who add completion to help spell the new variables), > not a replacement. And orderly submission of patches that are related and > have dependencies is a prime example of such coordination. Well, yes. But on the other hand, they are two totally separate topics; they just happen to both have a component of "add stuff to config completion". And don't you always preach about not holding one topic hostage by introducing an unnecessary dependency on another? I don't think it is a huge deal in this case, but Martin's patch could theoretically be "maint" material (I say theoretically because I didn't actually check whether any of the added completions were for things not yet in maint). Basing it on something in "next", even if you wait until it's in "master", makes that impossible. But this is all philosphical wankery. I think any of the solutions is fine. -Peff -- 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