diff options
author | Jonathan Tan <jonathantanmy@google.com> | 2019-01-10 11:36:45 -0800 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2019-01-10 14:53:35 -0800 |
commit | bd0b42aed3084bf66557485fd7d87e975a4f6d4e (patch) | |
tree | 3687936d9bd551986a68a23e665ec169e08194bd /contrib/workdir/git-new-workdir | |
parent | First batch after 2.20.1 (diff) | |
download | tgif-bd0b42aed3084bf66557485fd7d87e975a4f6d4e.tar.xz |
fetch-pack: do not take shallow lock unnecessarily
When fetching using protocol v2, the remote may send a "shallow-info"
section if the client is shallow. If so, Git as the client currently
takes the shallow file lock, even if the "shallow-info" section is
empty.
This is not a problem except that Git does not support taking the
shallow file lock after modifying the shallow file, because
is_repository_shallow() stores information that is never cleared. And
this take-after-modify occurs when Git does a tag-following fetch from a
shallow repository on a transport that does not support tag following
(since in this case, 2 fetches are performed).
To solve this issue, take the shallow file lock (and perform all other
shallow processing) only if the "shallow-info" section is non-empty;
otherwise, behave as if it were empty.
A full solution (probably, ensuring that any action of committing
shallow file locks also includes clearing the information stored by
is_repository_shallow()) would solve the issue without need for this
patch, but this patch is independently useful (as an optimization to
prevent writing a file in an unnecessary case), hence why I wrote it. I
have included a NEEDSWORK outlining the full solution.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/workdir/git-new-workdir')
0 files changed, 0 insertions, 0 deletions