git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] fetch-pack: demonstrate --all breakage when remote have tags to non-commit objects

From
Jeff King <peff@peff.net>
Date
Jun 11, 2018, 04:20 UTC
Message-ID
<20180611042016.GA31642@sigill.intra.peff.net>
In-Reply-To
<20180610143231.7131-1-kirr@nexedi.com>
On Sun, Jun 10, 2018 at 02:32:57PM +0000, Kirill Smelkov wrote:
> Added test shows remote with two tag objects pointing to a blob and a
> tree. The tag objects themselves are referenced from under regular
> refs/tags/* namespace. If test_expect_failure is changed to
> test_expect_success the test fails:
Interesting case. The problem is actually that upload-pack complains:
> 	fatal: git upload-pack: not our ref 038f48ad0beaffbea71d186a05084b79e3870cbf
And that sha1 is the tagged blob:
> 	bc4e9e1fa80662b449805b1ac29fc9b1e4c49187        refs/tags/tag-to-blob			# <-- NOTE
> 	038f48ad0beaffbea71d186a05084b79e3870cbf        refs/tags/tag-to-blob^{}
> 	520db1f5e1afeaa12b1a8d73ce82db72ca036ee1        refs/tags/tag-to-tree			# <-- NOTE
> 	7395c100223b7cd760f58ccfa0d3f3d2dd539bb6        refs/tags/tag-to-tree^{}

So it seems like upload-pack is at fault for not marking the object as a tip when it peels the tag.

> For the reference, porcelain fetch 'refs/*:refs/origin/*' works:

That's because it doesn't actually issue a "want" for the peeled blob (it doesn't need to, because it's fetching the tag itself). So it happens to work, but I still think upload-pack is at fault for not accepting the "want" on the blob it advertised.

Doubly interesting, it looks like this case _used_ to work, but was broken by 5f0fc64513 (fetch-pack: eliminate spurious error messages, 2012-09-09). Which only changed the fetch-pack side. It moved the handling of --all so that it was no longer in the "else" for check_refname_format(). I guess the original code was rejecting those peeled bits as "not a ref" (which makes sense).

So that seems like a bug in fetch-pack. But I'm still not convinced that upload-pack doesn't also have a bug.

> +test_expect_failure 'test --all wrt tag to non-commits' '
> +	blob_sha1=$(echo "hello blob" | git hash-object -t blob -w --stdin) &&
> +	git tag -a -m "tag -> blob" tag-to-blob $blob_sha1 &&
> +	tree_sha1=$(echo -e "100644 blob $blob_sha1\tfile" | git mktree) &&
I had to switch this "echo -e" to:
  printf "100644 blob $blob_sha1\tfile\n"
since "-e" is a bash-ism (and my /bin/sh is dash).
-Peff
Previous: Kirill SmelkovNext: Jeff King
Message 2 of 21 in “fetch-pack: demonstrate --all breakage when remote have tags to non-commit objects”
  1. fetch-pack: demonstrate --all breakage when remote have tags to non-commit objectsKirill Smelkov, Jun 10, 2018
  2. Jeff KingJun 11, 2018
  3. fetch-pack: don't try to fetch peeled values with --allJeff King, Jun 11, 2018
  4. Eric SunshineJun 11, 2018
  5. fetch-pack: don't try to fetch peel values with --allJeff King, Jun 11, 2018
  6. Kirill SmelkovJun 11, 2018
  7. Jeff KingJun 12, 2018
  8. Kirill SmelkovJun 12, 2018
  9. fetch-pack: test explicitly that --all can fetch tag references pointing to non-commitsKirill Smelkov, Jun 13, 2018
  10. Junio C HamanoJun 13, 2018
  11. Kirill SmelkovJun 13, 2018
  12. Jeff KingJun 13, 2018
  13. Jeff KingJun 13, 2018
  14. Kirill SmelkovJun 14, 2018
  15. Junio C HamanoJun 14, 2018
  16. Kirill SmelkovJun 14, 2018
  17. fetch-pack: demonstrate --all failure when remote is emptyKirill Smelkov, Jun 13, 2018
  18. Junio C HamanoJun 13, 2018
  19. Kirill SmelkovJun 13, 2018
  20. Jeff KingJun 13, 2018
  21. Kirill SmelkovJun 14, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.