From: Junio C Hamano <gitster@pobox.com>
To: Eli Schwartz <eschwartz@archlinux.org>
Cc: git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH 3/3] pretty: add abbrev option to %(describe)
Date: Sat, 23 Oct 2021 22:15:55 -0700 [thread overview]
Message-ID: <xmqqv91n57g4.fsf@gitster.g> (raw)
In-Reply-To: <20211024014256.3569322-4-eschwartz@archlinux.org> (Eli Schwartz's message of "Sat, 23 Oct 2021 21:42:56 -0400")
Eli Schwartz <eschwartz@archlinux.org> writes:
> The %(describe) placeholder by default, like `git describe`, uses a
> seven-character abbreviated commit hash. This may not be sufficient to
"hash" -> "object name".
> fully describe all git repos, resulting in a placeholder replacement
"all git repos" -> "all commits in a given repository" (there may be
other valid way to clarify, but the point is that 'describe' does
not describe 'git repos' in the sense that my repository gets
description X while your repository gets description Y).
> changing its length because the repository grew in size. This could
> cause the output of git-archive to change.
>
> Add the --abbrev option to `git describe` to the placeholder interface
> in order to provide tools to the user for fine-tuning project defaults
> and ensure reproducible archives.
Note that it is sad that --abbrev=<n> does not necessarily ensure
reproducibility. To be more precise, I do not think it sacrifices
uniqueness to make the output reproducible. You can get more than N
hex-digits in the output if N is too small to ensure uniquness.
So it indeed is that this line of thought ...
> One alternative would be to just always specify --abbrev=40 but this may
> be a bit too biased...
... to use --abbrev=999 (because 40 is not the length of a full
object name in the SHA-2 world) is the only reasonable way, if what
you care about is the reproducibility.
Side note. I think "git describe --no-abbrev" is buggy in that
it does not give a full object name; I didn't check the code,
but it appears to be behaving the same way as "git describe
--abbrev=0" (show no hexdigits). Fixing this bug may possibly
be a low-hanging fruit.
But even if the feature cannot be used to guarantee a full
reproducibility, it is a good thing that we can now add this feature
with minimum effort thanks to the previous two steps.
The refactoring I suggested in my review for the previous step will
shine, if we want to do a good job parsing the --abbrev=<n> option,
since such a code organization would make it a fairly easy addition
to introduce "integer" type that calls match_placeholder_arg_value()
to read the option value (like "string" does) and validate that the
value is indeed an integer.
Would we want to support "--contains" as another boolean type? How
about "--all" and "--long"? All three sound plausible candidates.
Thanks.
next prev parent reply other threads:[~2021-10-24 5:16 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz
2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz
2021-10-24 4:31 ` Junio C Hamano
2021-10-24 15:37 ` Eli Schwartz
2021-10-24 1:42 ` [PATCH 2/3] pretty: add tag option to %(describe) Eli Schwartz
2021-10-24 4:57 ` Junio C Hamano
2021-10-24 15:38 ` Eli Schwartz
2021-10-24 1:42 ` [PATCH 3/3] pretty: add abbrev " Eli Schwartz
2021-10-24 5:15 ` Junio C Hamano [this message]
2021-10-24 15:43 ` Eli Schwartz
2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz
2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz
2021-10-26 5:18 ` Eric Sunshine
2021-10-26 20:05 ` Eli Schwartz
2021-10-26 1:34 ` [PATCH v2 2/3] pretty: add tag option to %(describe) Eli Schwartz
2021-10-26 5:25 ` Eric Sunshine
2021-10-26 20:06 ` Eli Schwartz
2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz
2021-10-26 5:36 ` Eric Sunshine
2021-10-26 12:06 ` Đoàn Trần Công Danh
2021-10-26 17:28 ` Eric Sunshine
2021-10-26 19:12 ` Eli Schwartz
2021-10-27 8:05 ` Carlo Arenas
2021-11-03 23:20 ` Johannes Schindelin
2021-11-04 9:29 ` Johannes Schindelin
2021-11-07 12:39 ` Eli Schwartz
2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz
2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz
2021-10-29 20:11 ` Junio C Hamano
2021-10-29 21:06 ` Eli Schwartz
2021-10-29 21:34 ` Junio C Hamano
2021-10-29 18:45 ` [PATCH v3 2/3] pretty: add tag option to %(describe) Eli Schwartz
2021-10-29 20:18 ` Junio C Hamano
2021-10-29 21:14 ` Eli Schwartz
2021-10-29 21:46 ` Junio C Hamano
2021-10-29 21:28 ` Junio C Hamano
2021-10-29 21:44 ` Eli Schwartz
2021-10-29 18:45 ` [PATCH v3 3/3] pretty: add abbrev " Eli Schwartz
2021-10-29 18:51 ` Eric Sunshine
2021-10-29 19:04 ` Eli Schwartz
2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz
2021-10-31 17:15 ` [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz
2021-10-31 17:15 ` [PATCH v4 2/3] pretty: add tag option to %(describe) Eli Schwartz
2021-10-31 18:07 ` Junio C Hamano
2021-10-31 18:58 ` Eli Schwartz
2021-10-31 17:15 ` [PATCH v4 3/3] pretty: add abbrev " Eli Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv91n57g4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=eschwartz@archlinux.org \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).