Jeff King <peff@xxxxxxxx> writes: > On Wed, Dec 15, 2010 at 08:44:45PM +0100, Martin von Zweigbergk wrote: > >> > One note: >> > >> > > color.diff >> > > color.diff.commit >> > > color.diff.frag >> > > + color.diff.func >> > > color.diff.meta >> > > color.diff.new >> > > color.diff.old >> > > color.diff.plain >> > > color.diff.whitespace >> > >> > 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 ;-). > In this case, it might be OK to just start shipping color.diff.branch in > the completion list. It doesn't hurt anything to have the extra > completion before the feature is in, and the feature seems very likely > to make it in soon. > > 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. 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. -- 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