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). > > Strictly speaking, that note is for Junio to think of when he merges, > right? But adding it early is pretty harmless and if that relieves him > of some work, I would be happy to add it in the next submission of > this patch. Is that better? > > Thinking a bit more, maybe what you are suggesting is that I base the > next revision of this patch on the branch that adds that variable? 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. 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. :) -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