git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  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).