{"thread":{"id":"40948","subject":"[PATCH 2/2] format-patch: add an option to suppress commit hash","startedAt":"2015-12-06T22:16:34Z","lastAt":"2015-12-08T18:18:28Z","messageCount":10,"participants":["brian m. carlson","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"274087","messageId":"1449440196-991107-1-git-send-email-sandals@crustytoothpaste.net","threadId":"40948","inReplyTo":null,"subject":"[PATCH 0/2] format-patch: introduce option to suppress commit hashes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-06T22:16:34Z","receivedAt":"2015-12-06T22:16:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"git format-patch is often used to create patches that are then stored in\nversion control or displayed with diff. Having the commit hash in the\n\"From \" line usually just creates diff noise in these cases, so this\nseries introduces --no-hash to set that to all zeros.\n\nThe idea for this series came from Dominic Hargreaves in Debian bug\n#635663.\n\nThis series is based off of next so as not to conflict with the\nconversion of struct object to struct object_id.\n\nCareful readers will note that this option is referred to by both\n\"no_hash\" and \"zero_commit\". I felt that the latter made more sense as\nan option in struct rev_info, as it's strictly more accurate, while the\nformer is less accurate but more friendly to humans. Of course, this\ncan be changed if reviewers feel it to be undesirable.\n\nbrian m. carlson (2):\n Introduce a null_oid constant.\n format-patch: add an option to suppress commit hash\n\n Documentation/git-format-patch.txt | 4 ++++\n builtin/log.c | 5 +++++\n cache.h | 1 +\n log-tree.c | 3 ++-\n revision.h | 1 +\n sha1_file.c | 1 +\n t/t4014-format-patch.sh | 6 ++++++\n 7 files changed, 20 insertions(+), 1 deletion(-)\n\n-- \n2.6.3.658.g85d7f57\n"},{"id":"274086","messageId":"1449440196-991107-2-git-send-email-sandals@crustytoothpaste.net","threadId":"40948","inReplyTo":"1449440196-991107-1-git-send-email-sandals@crustytoothpaste.net","subject":"[PATCH 1/2] Introduce a null_oid constant.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-06T22:16:35Z","receivedAt":"2015-12-06T22:16:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"null_oid is the struct object_id equivalent to null_sha1.\n\nSigned-off-by: brian m. carlson \n---\n cache.h | 1 +\n sha1_file.c | 1 +\n 2 files changed, 2 insertions(+)\n\ndiff --git a/cache.h b/cache.h\nindex 5ab6cb50..c63fcc11 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -831,6 +831,7 @@ extern const char *find_unique_abbrev(const unsigned char *sha1, int len);\n extern int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len);\n \n extern const unsigned char null_sha1[GIT_SHA1_RAWSZ];\n+extern const struct object_id null_oid;\n \n static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2)\n {\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 27ce7b70..a54deb05 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -36,6 +36,7 @@\n static inline uintmax_t sz_fmt(size_t s) { return s; }\n \n const unsigned char null_sha1[20];\n+const struct object_id null_oid;\n \n /*\n * This is meant to hold a *small* number of objects that you would\n-- \n2.6.3.658.g85d7f57\n"},{"id":"274085","messageId":"1449440196-991107-3-git-send-email-sandals@crustytoothpaste.net","threadId":"40948","inReplyTo":"1449440196-991107-1-git-send-email-sandals@crustytoothpaste.net","subject":"[PATCH 2/2] format-patch: add an option to suppress commit hash","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-06T22:16:36Z","receivedAt":"2015-12-06T22:16:36Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Oftentimes, patches created by git format-patch will be stored in\nversion control or compared with diff. In these cases, two otherwise\nidentical patches can have different commit hashes, leading to diff\nnoise. Teach git format-patch a --no-hash option that instead produces\nan all-zero hash to avoid this diff noise.\n\nSigned-off-by: brian m. carlson \n---\n Documentation/git-format-patch.txt | 4 ++++\n builtin/log.c | 5 +++++\n log-tree.c | 3 ++-\n revision.h | 1 +\n t/t4014-format-patch.sh | 6 ++++++\n 5 files changed, 18 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 40356491..1266f135 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -256,6 +256,10 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.\n \tusing this option cannot be applied properly, but they are\n \tstill useful for code review.\n \n+--no-hash::\n+ Output an all-zero hash in each patch's From header instead\n+ of the hash of the commit.\n+\n --root::\n \tTreat the revision argument as a , even if it\n \tis just a single commit (that would normally be treated as a\ndiff --git a/builtin/log.c b/builtin/log.c\nindex 069bd3a9..774ec1bf 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -1196,6 +1196,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \tint cover_letter = -1;\n \tint boundary_count = 0;\n \tint no_binary_diff = 0;\n+\tint no_hash = 0;\n \tstruct commit *origin = NULL;\n \tconst char *in_reply_to = NULL;\n \tstruct patch_ids ids;\n@@ -1236,6 +1237,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\t\t PARSE_OPT_NOARG | PARSE_OPT_NONEG, keep_callback },\n \t\tOPT_BOOL(0, \"no-binary\", &no_binary_diff,\n \t\t\t N_(\"don't output binary diffs\")),\n+\t\tOPT_BOOL(0, \"no-hash\", &no_hash,\n+\t\t\t N_(\"output all-zero hash in From header\")),\n \t\tOPT_BOOL(0, \"ignore-if-in-upstream\", &ignore_if_in_upstream,\n \t\t\t N_(\"don't include a patch matching a commit upstream\")),\n \t\t{ OPTION_SET_INT, 'p', \"no-stat\", &use_patch_format, NULL,\n@@ -1380,6 +1383,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t/* Always generate a patch */\n \trev.diffopt.output_format |= DIFF_FORMAT_PATCH;\n \n+\trev.zero_commit = no_hash;\n+\n \tif (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)\n \t\tDIFF_OPT_SET(&rev.diffopt, BINARY);\n \ndiff --git a/log-tree.c b/log-tree.c\nindex 35e78017..f70a30e1 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -342,7 +342,8 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,\n {\n \tconst char *subject = NULL;\n \tconst char *extra_headers = opt->extra_headers;\n-\tconst char *name = oid_to_hex(&commit->object.oid);\n+\tconst char *name = oid_to_hex(opt->zero_commit ?\n+\t\t\t\t &null_oid : &commit->object.oid);\n \n \t*need_8bit_cte_p = 0; /* unknown */\n \tif (opt->total > 0) {\ndiff --git a/revision.h b/revision.h\nindex 5bc96868..23857c0e 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -135,6 +135,7 @@ struct rev_info {\n \t\t\tpretty_given:1,\n \t\t\tabbrev_commit:1,\n \t\t\tabbrev_commit_given:1,\n+\t\t\tzero_commit:1,\n \t\t\tuse_terminator:1,\n \t\t\tmissing_newline:1,\n \t\t\tdate_mode_explicit:1,\ndiff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh\nindex 890db117..ce8313c7 100755\n--- a/t/t4014-format-patch.sh\n+++ b/t/t4014-format-patch.sh\n@@ -1431,4 +1431,10 @@ test_expect_success 'cover letter auto user override' '\n \ttest_line_count = 2 list\n '\n \n+test_expect_success 'format-patch --no-hash' '\n+\tgit format-patch --no-hash --stdout v2..v1 >patch2 &&\n+\tcnt=$(egrep \"^From 0+ Mon Sep 17 00:00:00 2001\" patch2 | wc -l) &&\n+\ttest $cnt = 3\n+'\n+\n test_done\n-- \n2.6.3.658.g85d7f57\n"},{"id":"274090","messageId":"xmqqh9jvnfbp.fsf@gitster.mtv.corp.google.com","threadId":"40948","inReplyTo":"1449440196-991107-1-git-send-email-sandals@crustytoothpaste.net","subject":"Re: [PATCH 0/2] format-patch: introduce option to suppress commit hashes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-07T02:49:14Z","receivedAt":"2015-12-07T02:49:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> git format-patch is often used to create patches that are then stored in\n> version control or displayed with diff. Having the commit hash in the\n> \"From \" line usually just creates diff noise in these cases, so this\n> series introduces --no-hash to set that to all zeros.\n\nI am somewhat negative on this change that deliberately loses\ninformation in a way that seems too specific to a single workflow.\n\nI understand that in that particular workflow, the patch stored as\npayload in a history needs only the diff part and the commit that\nthe patch was taken from is deemed irrelevant.\n\nBut the reason why that and only that piece of information is\nexpendable, while author, subject and log message text are not is\nbecause...? The answer to that question would very much be\nproject's workflow dependant. From that point of view, I'd say the\nusers are much better off without the addition of this feature, but\nhave a custom script in their workflow to remove parts that their\nproject and workflow deems unnecessary. Your project may deem the\nsource commit object name unnecessary. Another one may think the\nauthor date and name are, too. Patch e-mail signature (i.e. what\ncomes after a line with \"-- \") by default depends on the version of\nGit that happened to have been used to prepare the patch, which may\nnot be something you would want.\n\nStepping back a bit, why is the history from which the patches are\ntaken from irrelevant in the first place? Perhaps because you\nreplayed these patches on top of the same base but did not preserve\ntheir timestamps? If this user, i.e. the part of the workflow that\ncommits generated patches to version control, finds the \"irrelevant\"\nchange irritating, isn't it fair to expect other users, i.e. other\nparts of the same workflow, also find that unnecessary and\nirrelevant rebasing irritating? It feels like I am seeing an\nentrance to an X-Y problem whose real solution is to stop doing the\npointless rebases in the first place.\n\nAnd if that rebase is not pointless, then I am not sure if it is a\ngood thing to discard the information that records which incarnation\nof that constantly rebased source tree the patches were taken from.\n\nSo...\n"},{"id":"274092","messageId":"20151207033020.GA990758@vauxhall.crustytoothpaste.net","threadId":"40948","inReplyTo":"xmqqh9jvnfbp.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 0/2] format-patch: introduce option to suppress commit hashes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-07T03:30:20Z","receivedAt":"2015-12-07T03:30:20Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Dec 06, 2015 at 06:49:14PM -0800, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > git format-patch is often used to create patches that are then stored in\n> > version control or displayed with diff. Having the commit hash in the\n> > \"From \" line usually just creates diff noise in these cases, so this\n> > series introduces --no-hash to set that to all zeros.\n> \n> I am somewhat negative on this change that deliberately loses\n> information in a way that seems too specific to a single workflow.\n> \n> I understand that in that particular workflow, the patch stored as\n> payload in a history needs only the diff part and the commit that\n> the patch was taken from is deemed irrelevant.\n\nNot exactly. At $DAYJOB, we store pristine-tar files, the contents of\nthe tarball, and patches against the source in Git. We do it because\nRPM likes patches and doesn't know how to speak to Git, but many Debian\nsource packages are stored similarly. Every source change results in a\nrebase and reformat of all the patches.\n\n> But the reason why that and only that piece of information is\n> expendable, while author, subject and log message text are not is\n> because...? The answer to that question would very much be\n> project's workflow dependant. From that point of view, I'd say the\n> users are much better off without the addition of this feature, but\n> have a custom script in their workflow to remove parts that their\n> project and workflow deems unnecessary. Your project may deem the\n> source commit object name unnecessary. Another one may think the\n> author date and name are, too. Patch e-mail signature (i.e. what\n> comes after a line with \"-- \") by default depends on the version of\n> Git that happened to have been used to prepare the patch, which may\n> not be something you would want.\n\nWe do want to know who wrote the patch and the reason behind the patch,\nand so pretty much all the information except for the actual hash of the\ncommit is useful to us. The hash is not useful because we've just\nrebased the commit on a temporary branch. We do, of course, want\n--no-signature, which already exists, as you pointed out.\n\nThe hash of the source file isn't generally as much of a problem,\nbecause the patch tends to change, even incidentally (line numbers and\nsuch), when the hash of the file changes. It's also something that we\nhave in our history, whereas the temporary branch we rebased in is not.\n\n> Stepping back a bit, why is the history from which the patches are\n> taken from irrelevant in the first place? Perhaps because you\n> replayed these patches on top of the same base but did not preserve\n> their timestamps? If this user, i.e. the part of the workflow that\n> commits generated patches to version control, finds the \"irrelevant\"\n> change irritating, isn't it fair to expect other users, i.e. other\n> parts of the same workflow, also find that unnecessary and\n> irrelevant rebasing irritating? It feels like I am seeing an\n> entrance to an X-Y problem whose real solution is to stop doing the\n> pointless rebases in the first place.\n\nThe history is irrelevant because it happens on a temporary branch which\nis not pushed anywhere. The patches are the canonical form. As I said,\nthis workflow is not specific to us; it's also used by certain Debian\nmaintainers to handle their source packages.\n\nThe rebase is required because we're not sure if the patches all apply\nto the updated source (e.g. we had Git 2.6.2 and are rebasing them on\n2.6.3). If patch 1 needed changes, but patch 2 did not, then patch 2\nshows up in the diff even though we don't want it to.\n\n> And if that rebase is not pointless, then I am not sure if it is a\n> good thing to discard the information that records which incarnation\n> of that constantly rebased source tree the patches were taken from.\n\nI was looking through the Debian BTS for Git and I saw this feature\nrequest and thought, \"Gee, I've always wanted this functionality, but I\nnever thought to ask for it.\" This frequent, throwaway rebasing is very\ncommon in patch-based workflows.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"274104","messageId":"xmqq8u56oehi.fsf@gitster.mtv.corp.google.com","threadId":"40948","inReplyTo":"20151207033020.GA990758@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH 0/2] format-patch: introduce option to suppress commit hashes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-07T08:22:01Z","receivedAt":"2015-12-07T08:22:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> The hash of the source file isn't generally as much of a problem,\n> because the patch tends to change, even incidentally (line numbers and\n> such), when the hash of the file changes. It's also something that we\n> have in our history, whereas the temporary branch we rebased in is not.\n\nThat is exactly the kind of workflow specific reasoning that tells\nyou \"object name of the commit that the patch was taken from is the\nonly thing that is undesired\" that makes me wonder if the feature is\ntoo workflow specific. You do something on a temporary branch without\nworrying about producing unnecessary object name churn, and end up\nwanting not to see object names.\n\nBut I can buy that a step in the workflow to rebuild the history on\na temporary branch before going to the next step is a common thing\nto have, so let's decide to accept the goal as a good thing to have,\nand see how well the patched code implements, documents and tests\nthe advertised new feature.\n\nThanks.\n"},{"id":"274125","messageId":"xmqqr3iym4rg.fsf@gitster.mtv.corp.google.com","threadId":"40948","inReplyTo":"1449440196-991107-3-git-send-email-sandals@crustytoothpaste.net","subject":"Re: [PATCH 2/2] format-patch: add an option to suppress commit hash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-07T19:34:59Z","receivedAt":"2015-12-07T19:34:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> Oftentimes, patches created by git format-patch will be stored in\n> version control or compared with diff. In these cases, two otherwise\n> identical patches can have different commit hashes, leading to diff\n> noise. Teach git format-patch a --no-hash option that instead produces\n> an all-zero hash to avoid this diff noise.\n>\n> Signed-off-by: brian m. carlson \n> ---\n> Documentation/git-format-patch.txt | 4 ++++\n> builtin/log.c | 5 +++++\n> log-tree.c | 3 ++-\n> revision.h | 1 +\n> t/t4014-format-patch.sh | 6 ++++++\n> 5 files changed, 18 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\n> index 40356491..1266f135 100644\n> --- a/Documentation/git-format-patch.txt\n> +++ b/Documentation/git-format-patch.txt\n> @@ -256,6 +256,10 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.\n> \tusing this option cannot be applied properly, but they are\n> \tstill useful for code review.\n> \n> +--no-hash::\n> + Output an all-zero hash in each patch's From header instead\n> + of the hash of the commit.\n> +\n\nTwo (big) problems with the option name.\n\n - \"--no-something\" would mislead people to think you are removing\n something, not replacing it with something else. This option\n does the latter (i.e. the first line of your output still has\n 40-hex; it's just it no longer has a useful 40-hex).\n\n - There are many places we use hexadecimal strings in format-patch\n output and you are not removing or replacing all of them, only\n the commit object name on the fake \"From \" line. Saying \"hash\"\n would mislead readers.\n\n> +test_expect_success 'format-patch --no-hash' '\n> +\tgit format-patch --no-hash --stdout v2..v1 >patch2 &&\n> +\tcnt=$(egrep \"^From 0+ Mon Sep 17 00:00:00 2001\" patch2 | wc -l) &&\n\nDon't test \"any number of '0'\"; test 40 '0's. This is because the\nline format was designed to be usable by things like /etc/magic to\ndetect format-patch output, and we want to notice if/when we break\nthat aspect of our output format.\n\n> +\ttest $cnt = 3\n> +'\n> +\n> test_done\n\nThanks.\n"},{"id":"274128","messageId":"xmqqmvtmm46w.fsf@gitster.mtv.corp.google.com","threadId":"40948","inReplyTo":"xmqqr3iym4rg.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: add an option to suppress commit hash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-07T19:47:19Z","receivedAt":"2015-12-07T19:47:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> +--no-hash::\n>> + Output an all-zero hash in each patch's From header instead\n>> + of the hash of the commit.\n>> +\n>\n> Two (big) problems with the option name.\n>\n> - \"--no-something\" would mislead people to think you are removing\n> something, not replacing it with something else. This option\n> does the latter (i.e. the first line of your output still has\n> 40-hex; it's just it no longer has a useful 40-hex).\n>\n> - There are many places we use hexadecimal strings in format-patch\n> output and you are not removing or replacing all of them, only\n> the commit object name on the fake \"From \" line. Saying \"hash\"\n> would mislead readers.\n\nI am not good at bikeshedding, but you used 'zero_commit' elsewhere\nin the code. I think that would be a much better name--perhaps use\nthat consistently throughout, as the local variable in options[]\narray and end-user facing option name?\n\n>\n>> +test_expect_success 'format-patch --no-hash' '\n>> +\tgit format-patch --no-hash --stdout v2..v1 >patch2 &&\n>> +\tcnt=$(egrep \"^From 0+ Mon Sep 17 00:00:00 2001\" patch2 | wc -l) &&\n>\n> Don't test \"any number of '0'\"; test 40 '0's. This is because the\n> line format was designed to be usable by things like /etc/magic to\n> detect format-patch output, and we want to notice if/when we break\n> that aspect of our output format.\n>\n>> +\ttest $cnt = 3\n>> +'\n>> +\n>> test_done\n>\n> Thanks.\n"},{"id":"274161","messageId":"20151208010227.GC990758@vauxhall.crustytoothpaste.net","threadId":"40948","inReplyTo":"xmqqr3iym4rg.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 2/2] format-patch: add an option to suppress commit hash","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-08T01:02:27Z","receivedAt":"2015-12-08T01:02:27Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Dec 07, 2015 at 11:34:59AM -0800, Junio C Hamano wrote:\n> Two (big) problems with the option name.\n> \n> - \"--no-something\" would mislead people to think you are removing\n> something, not replacing it with something else. This option\n> does the latter (i.e. the first line of your output still has\n> 40-hex; it's just it no longer has a useful 40-hex).\n\nRight. I originally considered removing that line altogether, but other\nparts of Git rely on that header to process patches correctly.\n\n> - There are many places we use hexadecimal strings in format-patch\n> output and you are not removing or replacing all of them, only\n> the commit object name on the fake \"From \" line. Saying \"hash\"\n> would mislead readers.\n\nI'll reroll with the name --zero-commit, unless somebody comes up with a\nbetter suggestion.\n\n> > +test_expect_success 'format-patch --no-hash' '\n> > +\tgit format-patch --no-hash --stdout v2..v1 >patch2 &&\n> > +\tcnt=$(egrep \"^From 0+ Mon Sep 17 00:00:00 2001\" patch2 | wc -l) &&\n> \n> Don't test \"any number of '0'\"; test 40 '0's. This is because the\n> line format was designed to be usable by things like /etc/magic to\n> detect format-patch output, and we want to notice if/when we break\n> that aspect of our output format.\n\nMy idea was to future-proof it against changes in the hash function,\nalthough that's in the distant future. I'll reroll with the change you\nsuggested. I might drop in another patch to improve the existing tests\nto cover the case without this option, as I think we just look for\n\"From \" currently.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"274187","messageId":"xmqqa8pkls7f.fsf@gitster.mtv.corp.google.com","threadId":"40948","inReplyTo":"20151208010227.GC990758@vauxhall.crustytoothpaste.net","subject":"Re: [PATCH 2/2] format-patch: add an option to suppress commit hash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-08T18:18:28Z","receivedAt":"2015-12-08T18:18:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n>> Don't test \"any number of '0'\"; test 40 '0's. This is because the\n>> line format was designed to be usable by things like /etc/magic to\n>> detect format-patch output, and we want to notice if/when we break\n>> that aspect of our output format.\n>\n> My idea was to future-proof it against changes in the hash function,\n> although that's in the distant future.\n\nMaking sure that the test fails when somebody accidentally lengthens\n(or fails to truncate to 40-hex, when you start using a longer hash)\nthe displayed name there is a good future-proofing.\n\nThanks.\n"}]}