summaryrefslogtreecommitdiff
path: root/Documentation/technical/api-gitattributes.txt
diff options
context:
space:
mode:
authorLibravatar Jonathan Tan <jonathantanmy@google.com>2019-01-10 11:36:45 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-01-10 14:53:35 -0800
commitbd0b42aed3084bf66557485fd7d87e975a4f6d4e (patch)
tree3687936d9bd551986a68a23e665ec169e08194bd /Documentation/technical/api-gitattributes.txt
parentFirst batch after 2.20.1 (diff)
downloadtgif-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 'Documentation/technical/api-gitattributes.txt')
0 files changed, 0 insertions, 0 deletions