From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2728 invoked from network); 17 Apr 2022 20:09:18 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2022 20:09:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Subject:Cc:To:From:Date: References:In-Reply-To:Message-Id:Mime-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=M/Wa3JWnF/zSmFOYiHH2xm14v285mxwz+A/wC8F6j1Y=; b=UDlMb+YaKThHK38HnCPqk8/7aR 8fbM9cPFmvsV5q2mnSwgwNPXYGygLWbUltnXo32/ftf4AxbN4LIsBhRXjXJaSDLiQMY7V+Yv99JhL 3ZDBD4AKPWi4a45NqNiLY98WiR8heNzTvgJ5+WhqUyyB6Iy9ZWh3Jeje7+XcpV1Bx2e/w5z/HPiwa U3DTVFae3lM+U11BKoSp1F9neCDGOcOtTCwGwoSmu1dOO8fQtX6SBdSTRbPToCBZRfTdp5355PNMz vfS/1IZn71KESolgQYZZFv/6rEgtOYVKtHojyeFlDnLdVkBQAwdY1jYLoTcFOONlfj8bhqEPelIJ9 dT9R8UCg==; Received: from authenticated user by zero.zsh.org with local id 1ngBCw-000OkC-4N; Sun, 17 Apr 2022 20:09:18 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1ngBCf-000OQn-Bb; Sun, 17 Apr 2022 20:09:01 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id A83C027C0054; Sun, 17 Apr 2022 16:08:59 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Sun, 17 Apr 2022 16:08:59 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudelledgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpefnrgif rhgvnhgtvggpgggvlhojiihquhgviicuoehlrghrrhihvhesiihshhdrohhrgheqnecugg ftrfgrthhtvghrnhepieekjeevledugeefiefgueelgffgtddtgeehvedvhedviefghedv ffeuvddvueehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheplhgrrhhrhihvodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeh udekjeejtdegqdduudelvdejfeekhedqlhgrrhhrhihvpeepiihshhdrohhrghesfhgrsh htmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6246021E006E; Sun, 17 Apr 2022 16:08:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-387-g7ea99c4045-fm-20220413.002-g7ea99c40 Mime-Version: 1.0 Message-Id: In-Reply-To: <20220417175228.GP27526@tarpaulin.shahaf.local2> References: <58222599-b634-401b-b70f-3e5fd5633839@www.fastmail.com> <20220417175228.GP27526@tarpaulin.shahaf.local2> Date: Sun, 17 Apr 2022 16:08:34 -0400 From: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= To: "Daniel Shahaf" , "Sam Bostock" Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Abbreviate commit hash in prompt during git rebase Content-Type: text/plain X-Seq: 50076 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: On Sun, Apr 17, 2022, at 1:52 PM, Daniel Shahaf wrote: > Sam Bostock wrote on Wed, Apr 13, 2022 at 13:53:40 -0600: >> Git's abbreviation mechanism ensures uniqueness, rather than strictly >> truncating. If I'm not mistaken, the core.abbrev setting is effectively >> just a minimum for how many characters to include, with git including as >> many additional characters as required to avoid colliding with another >> object in the repository. I believe the default is determined using a >> heuristic based on the number objects in the repository. >> >> So we could make it a setting and do truncation ourselves, but then we'd be >> displaying a value without uniqueness guarantees. FWIW, this description of core.abbrev from git-config(1) (v2.35.1) doesn't say anything about *guaranteeing* uniqueness. core.abbrev Set the length object names are abbreviated to. If unspecified or set to "auto", an appropriate value is computed based on the approximate number of packed objects in your repository, which hopefully is enough for abbreviated object names to stay unique for some time. If set to "no", no abbreviation is made and the object names are shown in their full length. The minimum length is 4. If git really does ensure that abbreviated hashes are unique, then it's either documented elsewhere or not documented at all. The weather is very nice right now, so I shall decline to dive into the Git codebase at this time :) > So, do we actually need to *guarantee* uniqueness? I think allowing users to adjust truncation length through a style ought to suffice for users who need it. That would also avoid coupling prompt appearance to the configuration of a separate piece of software, which is a notion that I like less and less the more I think about it. I can easily imagine a user who might want to see full hashes in Git output but not in their prompt. -- vq