mbox series

[0/2] Fix empty SHA-256 clones with v0 and v1

Message ID 20230426205324.326501-1-sandals@crustytoothpaste.net (mailing list archive)
Headers show
Series Fix empty SHA-256 clones with v0 and v1 | expand

Message

brian m. carlson April 26, 2023, 8:53 p.m. UTC
We recently fixed empty clones with SHA-256 over protocol v2 by
honouring the hash algorithm specified even when no refs are present.
However, in doing so, we made it impossible to set up a v0 or v1
repository by cloning from an empty SHA-256 repository.  In doing so, we
also broke the Git LFS testsuite for SHA-256 repositories.

This series consists of two patches.  The first introduces the dummy
`capabilities^{}` entry for fetches and clones from an empty repository
for v0 and v1, just as we do for clones.  This is already supported by
older versions of Git, as well as libgit2 and JGit.

The second introduces some backwards compatibility to avoid regressing
the old behaviour of using GIT_DEFAULT_HASH to initialize the proper
hash in this case.  We add a flag to see if we explicitly obtained a
hash algorithm from the remote side, and if not, we honour
GIT_DEFAULT_HASH, as before.

brian m. carlson (2):
  http: advertise capabilities when cloning empty repos
  Honor GIT_DEFAULT_HASH for empty clones without remote algo

 Documentation/git.txt       | 10 +++++++---
 builtin/clone.c             |  8 +++++---
 connect.c                   |  5 ++++-
 pkt-line.h                  |  2 ++
 t/t5551-http-fetch-smart.sh | 27 +++++++++++++++++++++++++++
 t/t5700-protocol-v1.sh      | 32 ++++++++++++++++++++++++++++++--
 transport-helper.c          |  1 +
 transport.c                 | 14 ++++++++++++++
 transport.h                 | 14 ++++++++++++++
 upload-pack.c               |  4 ++++
 10 files changed, 108 insertions(+), 9 deletions(-)

Comments

Junio C Hamano April 26, 2023, 9:12 p.m. UTC | #1
"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> The second introduces some backwards compatibility to avoid regressing
> the old behaviour of using GIT_DEFAULT_HASH to initialize the proper
> hash in this case.  We add a flag to see if we explicitly obtained a
> hash algorithm from the remote side, and if not, we honour
> GIT_DEFAULT_HASH, as before.

I am fairly negative on this half of the series.  The first one is
excellent, though.

THanks.