Re: [PATCH 1/2] status: really ignore config with --porcelain

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 1/2] status: really ignore config with --porcelain

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:57

Junio C Hamano [off-list ref] writes:
Jeff King [off-list ref] writes:
quoted
You lose the assertion that finalize_deferred_config has been called,
but I think the resulting code would be simpler, as it drops this
die("BUG") state entirely. Am I missing something?
Probably not.  Depending on "-z", NONE is sometimes converted to
PORCELAIN and sometimes left as-is.  I originally wanted to keep the
"unspecified" state as long as possible so that this deferred config
logic and the "-z" default logic can be kept separate.

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.

Re: [PATCH 1/2] status: really ignore config with --porcelain

From: Jeff King <hidden>
Date: 2016-06-15 22:57:57

On Fri, Jun 28, 2013 at 10:37:26AM -0700, Junio C Hamano wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help