| Message ID | cover.1573604516.git.jonathantanmy@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | More fetch_if_missing=0 removal | expand |
Jonathan Tan <jonathantanmy@google.com> writes: > (Whenever, at $DAY_JOB, we encounter an edge case with partial clone, we > have been submitting patches with test cases for "git fetch" or "git > clone" but sometimes not both, so between 6462d5eb9a and this patch set, > these edge cases would be covered too.) Thanks, wonderful.
This is based on jt/fetch-remove-lazy-fetch-plugging. This patch set both uses the work in commit 6462d5eb9a ("fetch: remove fetch_if_missing=0", 2019-11-08) and covers up some of the edge use cases that the aforementioned commit did not cover. Junio wrote in [1]: > What I am not certain about is if we are ready > to move to the right direction for the longer term, or we should still > be relying on the big-hammer global bit for expediency a bit longer. I'm not sure if this patch set is an argument for or against. I did think 6462d5eb9a would be sufficient (but as these patches prove, it was not), but at the same time, with the additional test coverage provided by these patches, the overall work might be worth cooking in next. (Whenever, at $DAY_JOB, we encounter an edge case with partial clone, we have been submitting patches with test cases for "git fetch" or "git clone" but sometimes not both, so between 6462d5eb9a and this patch set, these edge cases would be covered too.) [1] https://public-inbox.org/git/xmqqh83s8h3m.fsf@gitster-ct.c.googlers.com/ Jonathan Tan (2): clone: remove fetch_if_missing=0 promisor-remote: remove fetch_if_missing=0 builtin/clone.c | 3 --- connected.c | 3 ++- fetch-pack.c | 46 ++++++++++++++++++++++++++++++++-------------- promisor-remote.c | 3 --- 4 files changed, 34 insertions(+), 21 deletions(-)