Re: [PATCH 0/2] update internal patch-id to use "stable" algorithm

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2022, 19:16 UTC
Message-ID: <xmqqo7v81qsn.fsf@gitster.g>
In-Reply-To: <pull.1359.git.1663653505.gitgitgadget@gmail.com>

"Jerry Zhang via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Internal usage of patch-id in rebase / cherry-pick doesn't persist
> patch-ids, so there's no need to specifically invoke the unstable variant.
>
> This allows the unstable logic to be cleaned up.

While all of that may be true, two things are not explained.

 * Why does "unstable" need to be "cleaned up"?  Is that too dirty
   in what way?

 * If internal usage does not persist patch-ids generated by the
   machinery, why is it bad to be using the unstable variant?  A
   naïve expectation would be to make sure you use stable one if you
   want a future recomputation to give you the same result, but the
   opposite does not have to be always true.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.