Skip to content

Makefile: start fixing regression in c75c02f5

Ævar Arnfjörð Bjarmason requested to merge avar/fix-mr-3151-regressions into master

Start fixing the regressions in c75c02f5 (Makefile: Do not re-clone repos when rebuilding git/libgit2, 2021-02-17) noted in [A]. What I said in that comment:

This breaks e.g. upgrading from v2.29.0 to v2.29.1.

There's multiple bugs here:

1. The clone is --depth=1, but not the fetch, so if you need to bump a
   version we switch to a full clone

2. You do e.g. "git fetch v2.29.1", but this does not create a
   refs/tags/v2.29.1 locally, we just put it into FETCH_HEAD, this is
   unlike the clone --branch option. Thus upgrading a version will
   fetch it successfully, but then we die on the "switch".

3. You're doing rev-parse --verify <thing>^{tree}. Presumably to not
   pass a full SHA-1, why not just cat-file -t <thing>?  I tried
   fixing #1 (closed) by instead doing --no-tags <obj>:<obj> but that
   fails with trying to write a tag into refs/heads/. As an aside I
   think that's a bug in git's fetching logic, it should pick
   refs/tags/* as the local namespace in that case.

Then writing everything into refs/tags/*. But now e.g. if you specify
some SHA-1 it's just happenstance whether it works, did we slurp it
down in the initial clone?

This starts to fix at least some of that. Now if we see a new version we're going to create a refs/tags/* name for it (even if it's e.g. "master").

The --no-tags option is needed because that option really doesn't mean "no tags", it means "don't do tag following". Without it the "--depth 1" is pretty pointless.

This is still going to be buggy in the case where you specify e.g. "master" but that ref has moved.

A. !3151 (c75c02f5, comment 515460714)

Merge request reports