| Message ID | cover.1547677183.git.jonathantanmy@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Trying to revive GIT_TEST_PROTOCOL_VERSION | expand |
On Wed, Jan 16 2019, Jonathan Tan wrote: > Ævar, are you planning to revive GIT_TEST_PROTOCOL_VERSION? I have > updated the patchset in light of some new branches that have appeared. > > This is on master merged with: > - jk/proto-v2-hidden-refs-fix > - tg/t5570-drop-racy-test > - js/protocol-advertise-multi > - jt/upload-pack-deepen-relative-proto-v2 > - jt/fetch-pack-v2 I'm happy to have you pick that up as you've done here, especially since you're actually working on v2 and I'm not, so you can more easily know what it conflicts with etc. I just wanted to have it in one way or another, i.e. be able to deploy v2 and assert that "next + custom patches" doesn't break something for v2. I think [CC: Junio] that we shouldn't be concerned about an addition of GIT_TEST_PROTOCOL_VERSION patches in any form breaking the test suite under GIT_TEST_PROTOCOL_VERSION=2, and just be concerned about the default GIT_TEST_PROTOCOL_VERSION= case. I.e. if we have v2 patches in-flight that break things no big deal, we can always circle back and fix those things or annotate the tests.
> I'm happy to have you pick that up as you've done here, especially since > you're actually working on v2 and I'm not, so you can more easily know > what it conflicts with etc. I just wanted to have it in one way or > another, i.e. be able to deploy v2 and assert that "next + custom > patches" doesn't break something for v2. > > I think [CC: Junio] that we shouldn't be concerned about an addition of > GIT_TEST_PROTOCOL_VERSION patches in any form breaking the test suite > under GIT_TEST_PROTOCOL_VERSION=2, and just be concerned about the > default GIT_TEST_PROTOCOL_VERSION= case. I.e. if we have v2 patches > in-flight that break things no big deal, we can always circle back and > fix those things or annotate the tests. That sounds good to me. My main concern is that this will end up being dead code (if we have too many tests that fail with GIT_TEST_PROTOCOL_VERSION=2 and no one bothers with it anymore), but I don't think that will happen - in this patch set, I have eliminated a lot of false failures and strove to give reasons for the GIT_TEST_PROTOCOL_VERSION= annotations, and I think there's interest (well, at least from me) in investigating the remaining apparent bugs.
Jonathan Tan <jonathantanmy@google.com> writes: >> I'm happy to have you pick that up as you've done here, especially since >> you're actually working on v2 and I'm not, so you can more easily know >> what it conflicts with etc. I just wanted to have it in one way or >> another, i.e. be able to deploy v2 and assert that "next + custom >> patches" doesn't break something for v2. >> >> I think [CC: Junio] that we shouldn't be concerned about an addition of >> GIT_TEST_PROTOCOL_VERSION patches in any form breaking the test suite >> under GIT_TEST_PROTOCOL_VERSION=2, and just be concerned about the >> default GIT_TEST_PROTOCOL_VERSION= case. I.e. if we have v2 patches >> in-flight that break things no big deal, we can always circle back and >> fix those things or annotate the tests. > > That sounds good to me. My main concern is that this will end up being > dead code (if we have too many tests that fail with > GIT_TEST_PROTOCOL_VERSION=2 and no one bothers with it anymore), but I > don't think that will happen - in this patch set, I have eliminated a > lot of false failures and strove to give reasons for the > GIT_TEST_PROTOCOL_VERSION= annotations, and I think there's interest > (well, at least from me) in investigating the remaining apparent bugs. Yup, sounds good to me, too.