| Message ID | 20241202070714.3028549-4-gitster@pobox.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | forbid HEAD as a tagname | expand |
On Mon, Dec 2, 2024, at 08:07, Junio C Hamano wrote:
> 09116a1c (refs: loosen over-strict "format" check, 2011-11-16)
Nit/confusion: the abbreviated hash is only eight hexes long. I’m used to it
being 11 for this project?
Does the age of the commit matter?
On Mon, Dec 02, 2024 at 04:07:13PM +0900, Junio C Hamano wrote: > 09116a1c (refs: loosen over-strict "format" check, 2011-11-16) > introduced a test piece (originally in t5700) that expects to be > able to create a tag named "HEAD" and then a local clone using the > repository as its own reference works correctly. Later, another > test piece started using this tag starting at acede2eb (t5700: > document a failure of alternates to affect fetch, 2012-02-11). > > But the breakage 09116a1c fixed was not specific to the tagname > HEAD. It would have failed exactly the same way if the tag used > were foo instead of HEAD. > > Before forbidding "git tag" from creating "refs/tags/HEAD", update > these tests to use 'foo', not 'HEAD', as the name of the test tag. Yeah, I think this is worth doing independently. The patch looks good, though... > @@ -131,7 +131,7 @@ test_expect_success 'cloning with multiple references drops duplicates' ' > > test_expect_success 'clone with reference from a tagged repository' ' > ( > - cd A && git tag -a -m tagged HEAD > + cd A && git tag -a -m tagged foo > ) && > git clone --reference=A A I > ' > @@ -156,10 +156,10 @@ test_expect_success 'fetch with incomplete alternates' ' > git remote add J "file://$base_dir/J" && > GIT_TRACE_PACKET=$U.K git fetch J > ) && > - main_object=$(cd A && git for-each-ref --format="%(objectname)" refs/heads/main) && > + main_object=$(git -C A rev-parse --verify refs/heads/main) && > test -s "$U.K" && > ! grep " want $main_object" "$U.K" && > - tag_object=$(cd A && git for-each-ref --format="%(objectname)" refs/tags/HEAD) && > + tag_object=$(git -C A rev-parse --verify refs/tags/foo) && > ! grep " want $tag_object" "$U.K" > ' I notice that you swapped out "cd A && git" for "git -C A" in the second hunk (evne in the line which does not otherwise need to be touched). I think that is good, but is it worth doing the same in the first hunk? That would actually let us drop the subshell. -Peff
On Mon, Dec 02, 2024 at 01:19:56PM +0100, Kristoffer Haugsbakk wrote: > On Mon, Dec 2, 2024, at 08:07, Junio C Hamano wrote: > > 09116a1c (refs: loosen over-strict "format" check, 2011-11-16) > > Nit/confusion: the abbreviated hash is only eight hexes long. I’m used to it > being 11 for this project? It's not a fixed size. Long ago, the rule was "enough to be unique, but at least 7 (or whatever you set core.abbrev to)". These days that "7" is scaled based on the number of objects in the repo. See e6c587c733 (abbrev: auto size the default abbreviation, 2016-09-30). So I'd expect 10 digits in a fresh clone of git.git. It's possible Junio has set core.abbrev to something fixed, though. > Does the age of the commit matter? Nope, it shouldn't. -Peff
On Mon, Dec 2, 2024, at 22:00, Jeff King wrote: > On Mon, Dec 02, 2024 at 01:19:56PM +0100, Kristoffer Haugsbakk wrote: > >> On Mon, Dec 2, 2024, at 08:07, Junio C Hamano wrote: >> > 09116a1c (refs: loosen over-strict "format" check, 2011-11-16) >> >> Nit/confusion: the abbreviated hash is only eight hexes long. I’m used to it >> being 11 for this project? > > It's not a fixed size. Long ago, the rule was "enough to be unique, but > at least 7 (or whatever you set core.abbrev to)". These days that "7" is > scaled based on the number of objects in the repo. See e6c587c733 > (abbrev: auto size the default abbreviation, 2016-09-30). Yes. 11 was based on the output I get as well as what seemed normal in the recent git log. > > So I'd expect 10 digits in a fresh clone of git.git. It's possible Junio > has set core.abbrev to something fixed, though. > >> Does the age of the commit matter? > > Nope, it shouldn't. Makes sense. Thanks.
diff --git a/t/t5604-clone-reference.sh b/t/t5604-clone-reference.sh index 9b32db8478..5f5c650ff8 100755 --- a/t/t5604-clone-reference.sh +++ b/t/t5604-clone-reference.sh @@ -131,7 +131,7 @@ test_expect_success 'cloning with multiple references drops duplicates' ' test_expect_success 'clone with reference from a tagged repository' ' ( - cd A && git tag -a -m tagged HEAD + cd A && git tag -a -m tagged foo ) && git clone --reference=A A I ' @@ -156,10 +156,10 @@ test_expect_success 'fetch with incomplete alternates' ' git remote add J "file://$base_dir/J" && GIT_TRACE_PACKET=$U.K git fetch J ) && - main_object=$(cd A && git for-each-ref --format="%(objectname)" refs/heads/main) && + main_object=$(git -C A rev-parse --verify refs/heads/main) && test -s "$U.K" && ! grep " want $main_object" "$U.K" && - tag_object=$(cd A && git for-each-ref --format="%(objectname)" refs/tags/HEAD) && + tag_object=$(git -C A rev-parse --verify refs/tags/foo) && ! grep " want $tag_object" "$U.K" '
09116a1c (refs: loosen over-strict "format" check, 2011-11-16) introduced a test piece (originally in t5700) that expects to be able to create a tag named "HEAD" and then a local clone using the repository as its own reference works correctly. Later, another test piece started using this tag starting at acede2eb (t5700: document a failure of alternates to affect fetch, 2012-02-11). But the breakage 09116a1c fixed was not specific to the tagname HEAD. It would have failed exactly the same way if the tag used were foo instead of HEAD. Before forbidding "git tag" from creating "refs/tags/HEAD", update these tests to use 'foo', not 'HEAD', as the name of the test tag. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- t/t5604-clone-reference.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)