git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] format-patch: introduce option to suppress commit hashes

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 7, 2015, 02:49 UTC
Message-ID
<xmqqh9jvnfbp.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<1449440196-991107-1-git-send-email-sandals@crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> git format-patch is often used to create patches that are then stored in
> version control or displayed with diff.  Having the commit hash in the
> "From " line usually just creates diff noise in these cases, so this
> series introduces --no-hash to set that to all zeros.

I am somewhat negative on this change that deliberately loses information in a way that seems too specific to a single workflow.

I understand that in that particular workflow, the patch stored as payload in a history needs only the diff part and the commit that the patch was taken from is deemed irrelevant.

But the reason why that and only that piece of information is expendable, while author, subject and log message text are not is because...? The answer to that question would very much be project's workflow dependant. From that point of view, I'd say the users are much better off without the addition of this feature, but have a custom script in their workflow to remove parts that their project and workflow deems unnecessary. Your project may deem the source commit object name unnecessary. Another one may think the author date and name are, too. Patch e-mail signature (i.e. what comes after a line with "-- ") by default depends on the version of Git that happened to have been used to prepare the patch, which may not be something you would want.

Stepping back a bit, why is the history from which the patches are taken from irrelevant in the first place? Perhaps because you replayed these patches on top of the same base but did not preserve their timestamps? If this user, i.e. the part of the workflow that commits generated patches to version control, finds the "irrelevant" change irritating, isn't it fair to expect other users, i.e. other parts of the same workflow, also find that unnecessary and irrelevant rebasing irritating? It feels like I am seeing an entrance to an X-Y problem whose real solution is to stop doing the pointless rebases in the first place.

And if that rebase is not pointless, then I am not sure if it is a good thing to discard the information that records which incarnation of that constantly rebased source tree the patches were taken from.

So...
Previous: Junio C HamanoNext: brian m. carlson
Message 8 of 10 in “format-patch: introduce option to suppress commit hashes”
  1. 0/2 format-patch: introduce option to suppress commit hashesbrian m. carlson, Dec 6, 2015
  2. 1/2 Introduce a null_oid constant.brian m. carlson, Dec 6, 2015
  3. 2/2 format-patch: add an option to suppress commit hashbrian m. carlson, Dec 6, 2015
  4. Junio C HamanoDec 7, 2015
  5. Junio C HamanoDec 7, 2015
  6. brian m. carlsonDec 8, 2015
  7. Junio C HamanoDec 8, 2015
  8. Junio C HamanoDec 7, 2015
  9. brian m. carlsonDec 7, 2015
  10. Junio C HamanoDec 7, 2015

Read the whole thread, see it on lore, or plain text.

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