| Message ID | 20190328200456.29240-1-avarab@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] sha1-file: test the error behavior of alt_odb_usable() | expand |
On Thu, Mar 28, 2019 at 09:04:56PM +0100, Ævar Arnfjörð Bjarmason wrote: > Add a test for the error() case in alt_odb_usable() where an alternate > directory doesn't exist. This behavior has been the same since > 26125f6b9b ("detect broken alternates.", 2006-02-22), but if that > error() was turned into die() the entire test suite would still pass. > > Perhaps we should die() in that case, but let's start by adding a test > here to assert the long-standing existing behavior. I think if anything we might go the other direction, and downgrade the error() to a warning() or even omit it entirely. It's not an error to have a missing or transient alternate. Unless of course it has objects you need, but then those generate their own errors. I actually think in an ideal world we wouldn't say anything at all about alternates which aren't present, don't appear to contain objects, etc, on their own. And then when we hit an error because an object is missing, only _then_ diagnose and say "hey, you have this alternate but it doesn't have anything in it. Maybe that's an error?". Doing that diagnosis in the error path helps in two ways: - we don't have to worry about it being slow - we can be a bit more loose about things that _might_ be an issue. E.g., it's not an error to point to an alternate directory that has no files in it. It might be a misconfiguration, or it might just not have any objects right now. It's hard to justify complaining about it in _every_ git command that loads alternates. But after hitting a fatal error due to a missing object, it seems like a convenient thing to mention to the user. I suspect that implementing it that way might be a pain, though. Even if we had a convenient diagnose_missing_object() one-liner, there are probably dozens of separate places it would need to be called from. > diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh > index 895f46bb91..d2964c57b7 100755 > --- a/t/t5613-info-alternate.sh > +++ b/t/t5613-info-alternate.sh > @@ -136,4 +136,11 @@ test_expect_success CASE_INSENSITIVE_FS 'dup finding can be case-insensitive' ' > test_cmp expect actual.alternates > ' > > +test_expect_success 'print "error" on non-existing alternate' ' > + git init --bare I && > + echo DOES_NOT_EXIST >I/objects/info/alternates && > + git -C I fsck 2>stderr && > + test_i18ngrep "does not exist; check" stderr > +' All that said, I don't really have an objection against this patch, since it's just testing the current behavior. Anybody who wants to change it would find it pretty easy to tweak this test, too. -Peff
On Fri, Mar 29 2019, Jeff King wrote: > On Thu, Mar 28, 2019 at 09:04:56PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> Add a test for the error() case in alt_odb_usable() where an alternate >> directory doesn't exist. This behavior has been the same since >> 26125f6b9b ("detect broken alternates.", 2006-02-22), but if that >> error() was turned into die() the entire test suite would still pass. >> >> Perhaps we should die() in that case, but let's start by adding a test >> here to assert the long-standing existing behavior. > > I think if anything we might go the other direction, and downgrade the > error() to a warning() or even omit it entirely. It's not an error to > have a missing or transient alternate. Unless of course it has objects > you need, but then those generate their own errors. Yeah that sounds fine. FWIW it's just an "error" in the sense of being printed out by error(), but we proceed, so it's really a warning, sort-of. > I actually think in an ideal world we wouldn't say anything at all about > alternates which aren't present, don't appear to contain objects, etc, > on their own. And then when we hit an error because an object is > missing, only _then_ diagnose and say "hey, you have this alternate but > it doesn't have anything in it. Maybe that's an error?". Doing that > diagnosis in the error path helps in two ways: > > - we don't have to worry about it being slow > > - we can be a bit more loose about things that _might_ be an issue. > E.g., it's not an error to point to an alternate directory that has > no files in it. It might be a misconfiguration, or it might just not > have any objects right now. It's hard to justify complaining about > it in _every_ git command that loads alternates. But after hitting a > fatal error due to a missing object, it seems like a convenient > thing to mention to the user. > > I suspect that implementing it that way might be a pain, though. Even if > we had a convenient diagnose_missing_object() one-liner, there are > probably dozens of separate places it would need to be called from. > >> diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh >> index 895f46bb91..d2964c57b7 100755 >> --- a/t/t5613-info-alternate.sh >> +++ b/t/t5613-info-alternate.sh >> @@ -136,4 +136,11 @@ test_expect_success CASE_INSENSITIVE_FS 'dup finding can be case-insensitive' ' >> test_cmp expect actual.alternates >> ' >> >> +test_expect_success 'print "error" on non-existing alternate' ' >> + git init --bare I && >> + echo DOES_NOT_EXIST >I/objects/info/alternates && >> + git -C I fsck 2>stderr && >> + test_i18ngrep "does not exist; check" stderr >> +' > > All that said, I don't really have an objection against this patch, > since it's just testing the current behavior. Anybody who wants to > change it would find it pretty easy to tweak this test, too. Yup. Just wanted to get the patch to test what we do *currently* out, might loop back to finishing up the rest of this.
On Fri, Mar 29 2019, Ævar Arnfjörð Bjarmason wrote: > On Fri, Mar 29 2019, Jeff King wrote: > >> On Thu, Mar 28, 2019 at 09:04:56PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >>> Add a test for the error() case in alt_odb_usable() where an alternate >>> directory doesn't exist. This behavior has been the same since >>> 26125f6b9b ("detect broken alternates.", 2006-02-22), but if that >>> error() was turned into die() the entire test suite would still pass. >>> >>> Perhaps we should die() in that case, but let's start by adding a test >>> here to assert the long-standing existing behavior. >> >> I think if anything we might go the other direction, and downgrade the >> error() to a warning() or even omit it entirely. It's not an error to >> have a missing or transient alternate. Unless of course it has objects >> you need, but then those generate their own errors. > > Yeah that sounds fine. FWIW it's just an "error" in the sense of being > printed out by error(), but we proceed, so it's really a warning, > sort-of. > >> I actually think in an ideal world we wouldn't say anything at all about >> alternates which aren't present, don't appear to contain objects, etc, >> on their own. And then when we hit an error because an object is >> missing, only _then_ diagnose and say "hey, you have this alternate but >> it doesn't have anything in it. Maybe that's an error?". Doing that >> diagnosis in the error path helps in two ways: >> >> - we don't have to worry about it being slow >> >> - we can be a bit more loose about things that _might_ be an issue. >> E.g., it's not an error to point to an alternate directory that has >> no files in it. It might be a misconfiguration, or it might just not >> have any objects right now. It's hard to justify complaining about >> it in _every_ git command that loads alternates. But after hitting a >> fatal error due to a missing object, it seems like a convenient >> thing to mention to the user. >> >> I suspect that implementing it that way might be a pain, though. Even if >> we had a convenient diagnose_missing_object() one-liner, there are >> probably dozens of separate places it would need to be called from. >> >>> diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh >>> index 895f46bb91..d2964c57b7 100755 >>> --- a/t/t5613-info-alternate.sh >>> +++ b/t/t5613-info-alternate.sh >>> @@ -136,4 +136,11 @@ test_expect_success CASE_INSENSITIVE_FS 'dup finding can be case-insensitive' ' >>> test_cmp expect actual.alternates >>> ' >>> >>> +test_expect_success 'print "error" on non-existing alternate' ' >>> + git init --bare I && >>> + echo DOES_NOT_EXIST >I/objects/info/alternates && >>> + git -C I fsck 2>stderr && >>> + test_i18ngrep "does not exist; check" stderr >>> +' >> >> All that said, I don't really have an objection against this patch, >> since it's just testing the current behavior. Anybody who wants to >> change it would find it pretty easy to tweak this test, too. > > Yup. Just wanted to get the patch to test what we do *currently* out, > might loop back to finishing up the rest of this. Junio: *ping* about picking up this trivial test coverage improvement (missed in the latest What's Cooking).
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >> Yup. Just wanted to get the patch to test what we do *currently* out, >> might loop back to finishing up the rest of this. > > Junio: *ping* about picking up this trivial test coverage improvement I was waiting for you to make up your mind about your earlier "might loop back to finishing up". For a topic like this, for which the ball has been in your court for a long time, just resending would be easier to handle than pinging, as I do not remember much about the original attempt anyway ;-)
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >>>> +test_expect_success 'print "error" on non-existing alternate' ' >>>> + git init --bare I && >>>> + echo DOES_NOT_EXIST >I/objects/info/alternates && >>>> + git -C I fsck 2>stderr && >>>> + test_i18ngrep "does not exist; check" stderr >>>> +' >>> >>> All that said, I don't really have an objection against this patch, >>> since it's just testing the current behavior. Anybody who wants to >>> change it would find it pretty easy to tweak this test, too. >> >> Yup. Just wanted to get the patch to test what we do *currently* out, >> might loop back to finishing up the rest of this. > > Junio: *ping* about picking up this trivial test coverage improvement > (missed in the latest What's Cooking). I went back to the original thread to see what the patch was about. I actually am fairly negative on casting the current behaviour in stone for this one. Isn't the current status something like: we notice that we say 'error', we suspect that we would want to demote it to 'warning' or even silence, but this is not too pressing and it is OK as long as we do not make things worse by turning it into a more severe error. I do not mind if the last "look in stderr" step did not exist, though. It is good to make sure that fsck does not die when it sees a non-existing directory listed in the alternates file.
On Tue, Apr 09 2019, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > >>> Yup. Just wanted to get the patch to test what we do *currently* out, >>> might loop back to finishing up the rest of this. >> >> Junio: *ping* about picking up this trivial test coverage improvement > > I was waiting for you to make up your mind about your earlier "might > loop back to finishing up". For a topic like this, for which the > ball has been in your court for a long time, just resending would be > easier to handle than pinging, as I do not remember much about the > original attempt anyway ;-) I don't know when I'll get to finishing the rest of it. I'll leave it up to you if you want to queue just the test patch or drop it. I figured I'd re-send just that since I figured just fixing the blindspot of the current behavior would be a good thing on its own, not as an endorsement of the current behavior, just a "this is the current known behavior" regression test.
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > I'll leave it up to you if you want to queue just the test patch or drop As I said in a separate message, I think it is good to make sure that fsck does not crash. I do not think it is good to grep in its output. > it. I figured I'd re-send just that since I figured just fixing the > blindspot of the current behavior would be a good thing on its own, not > as an endorsement of the current behavior, just a "this is the current > known behavior" regression test. If the behaviour is undesirable one, we could document the current "breakage" with "test_expect_failure", whether we plan to fix it immediately. It is OK if readers cannot tell between a bug that is expected to stay forever with us, or a bug that somebody is actively working on. But unfortunately, there is no separate "test_merely_documenting", that is different from "test_expect_success", so even if we claim "this is not an endorsement, but is merely documenting the current behaviour" when we add such a test, there is no way for future readers to tell between the two, short of going back to "git blame" and seeing the log message. For that reason, I do not think it is a good practice to document the "current behaviour that happens to be" the same way as "the behaviour we desire" in test_expect_success.
On Tue, Apr 09, 2019 at 06:43:41PM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > I'll leave it up to you if you want to queue just the test patch or drop > > As I said in a separate message, I think it is good to make sure > that fsck does not crash. I do not think it is good to grep in its > output. FWIW, that approach (and your rationale below) makes a lot of sense to me for this case. -Peff
diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh index 895f46bb91..d2964c57b7 100755 --- a/t/t5613-info-alternate.sh +++ b/t/t5613-info-alternate.sh @@ -136,4 +136,11 @@ test_expect_success CASE_INSENSITIVE_FS 'dup finding can be case-insensitive' ' test_cmp expect actual.alternates ' +test_expect_success 'print "error" on non-existing alternate' ' + git init --bare I && + echo DOES_NOT_EXIST >I/objects/info/alternates && + git -C I fsck 2>stderr && + test_i18ngrep "does not exist; check" stderr +' + test_done
Add a test for the error() case in alt_odb_usable() where an alternate directory doesn't exist. This behavior has been the same since 26125f6b9b ("detect broken alternates.", 2006-02-22), but if that error() was turned into die() the entire test suite would still pass. Perhaps we should die() in that case, but let's start by adding a test here to assert the long-standing existing behavior. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- Unchanged from a 3-part series I submitted in December: https://public-inbox.org/git/20181204132716.19208-1-avarab@gmail.com/ Part of trying to re-submit the uncontentious parts of whatever I've submitted in the past that I have stalled for whatever reason... t/t5613-info-alternate.sh | 7 +++++++ 1 file changed, 7 insertions(+)