-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deserialize-status: silently fallback if we cannot read cache file #270
deserialize-status: silently fallback if we cannot read cache file #270
Conversation
Teach Git to not throw a fatal error when an explicitly-specified status-cache file (`git status --deserialize=<foo>`) could not be found or opened for reading and silently fallback to a traditional scan. This matches the behavior when the status-cache file is implicitly given via a config setting. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully understand the difference between do_explicit_deserialize
and do_implicit_deserialize
, but your tests look sufficient. Please just take a quick look at my comment to see if there is an issue or not.
do_explicit_deserialize = 1; /* read stdin */ | ||
else if (wt_status_deserialize_access(deserialize_path, R_OK) == 0) | ||
do_explicit_deserialize = 1; /* can read from this file */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fact that these two variables are the same made me wonder if this is the right approach, but you seem to test both cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming things is hard.
The variable do_implicit...
handles the case where we inherited a config setting. This was something that the gvfs installer set up and is usually outside of the user's view.
The do_explicit...
variable handles the --deserialize[=<path>]
command line option, which overrides the config setting. IIRC this was added later.
The original design was that if the path from the config was not found, silently ignore it and go on and do a scan -- since that would happen any time the gvfs service was having problems, for example, and the user wouldn't know why status was broken and they were getting an obscure error message.
But when given on the command line, usual practice is to complain if an input is not found.
But that hard error threw Jameson's test/expectations.
Hence the 2 different code paths in the original code for determining whether we can read the status-cache and whether to complain about it.
Structurally, the actual code change is a lot smaller than it looks, but I refactored it a bit for (hopefully) clarity. Perhaps I should have written it as:
if (path && *path && access(...)) {
do_implicit = 0
do_explicit = 0
return 0
}
deserialize-status: silently fallback if we cannot read cache file
deserialize-status: silently fallback if we cannot read cache file
Teach Git to not throw a fatal error when an explicitly-specified
status-cache file (
git status --deserialize=<foo>
) could not befound or opened for reading and silently fallback to a traditional
scan.
This matches the behavior when the status-cache file is implicitly
given via a config setting.
Signed-off-by: Jeff Hostetler jeffhost@microsoft.com