On Fri, Jun 28, 2013 at 10:37:26AM -0700, Junio C Hamano wrote: > > The final patch ended up folding that "-z" default logic into the > > same function, so it probably is saner to remove UNSPECIFIED. > > Actually, the code needs to be able to differentiate between > > git status --no-short > git status > > the former telling us explicitly to defeat status.short while the > latter telling us to use whatever random value we happen to have in > the configuration. Initializing the variable to UNSPECIFIED is one > way to achieve that, as the former will explicitly set it to NONE > while the latter will leave it UNSPECIFIED when the command line > parsing finishes. Hmm. I would have thought --no-short would just set it to LONG. That is, we are no longer NONE at that point, as the user has told us something on the command line. So we are whatever --no-short is, which is LONG. But I guess that would wreck git status --no-short -z which currently defaults to porcelain. Which, to be honest, seems a little crazy to me, but I guess there is no reason to break it. I am just trying to prevent the future maintenance confusion where a reader of the code says "Huh? What is the difference between NONE and UNSPECIFIED?" -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