| Message ID | 20241202070714.3028549-4-gitster@pobox.com (mailing list archive) |
|---|---|
| State | Superseded |
| 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.
Jeff King <peff@peff.net> writes: > 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. Thanks. I have "git one" (and "git who") aliased to this script: $ cat $(type --path git-onewho) #!/bin/sh if sha1=$(git rev-parse -q --verify "$1") then git show --date=short -s --abbrev=8 --pretty='format:%h (%s, %ad)' "$1" else git log -1 --format="%aN <%aE>" --author="$1" --all fi | tr -d "\012" $ git help one 'one' is aliased to 'onewho' $ git help who 'who' is aliased to 'onewho' so that I can say "\C-u ESC ! git one HEAD" (or "git one peff") while writing a piece of e-mail. I can drop --abbrev=8 from there but the machinery knows to bust that limit if it is necessary to ensure uniqueness, so ...
On Tue, Dec 03, 2024 at 10:29:14AM +0900, Junio C Hamano wrote: > I have "git one" (and "git who") aliased to this script: > > $ cat $(type --path git-onewho) > #!/bin/sh > if sha1=$(git rev-parse -q --verify "$1") > then > git show --date=short -s --abbrev=8 --pretty='format:%h (%s, %ad)' "$1" > else > git log -1 --format="%aN <%aE>" --author="$1" --all > fi | tr -d "\012" > $ git help one > 'one' is aliased to 'onewho' > $ git help who > 'who' is aliased to 'onewho' > > so that I can say "\C-u ESC ! git one HEAD" (or "git one peff") > while writing a piece of e-mail. I can drop --abbrev=8 from there > but the machinery knows to bust that limit if it is necessary to > ensure uniqueness, so ... Yeah, I have something similar. IMHO a manual --abbrev there is working against your goal. We do increase that to find a unique answer, but that is not very future-proof; it is only extending by one character taking into account what objects you have _now_. It might not be true for somebody else's repo with more objects, or even your own repo in the near future. The auto-scaling of core.abbrev done by default these days also suffers from that problem (it can only count how many objects you have now, not how many you expect to have a year from now). But I think our heuristics there give a bit higher safety margin for future-proofing the values. -Peff
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(-)