{"thread":{"id":"65597","subject":"[PATCH] doc: add caveat about turning off commit-graph","startedAt":"2026-05-05T20:45:53Z","lastAt":"2026-05-20T07:11:16Z","messageCount":12,"participants":["kristofferhaugsbakk@fastmail.com","Derrick Stolee","Kristoffer Haugsbakk","Junio C Hamano","Oswald Buddenhagen"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"542785","messageId":"caveat_commit-graph.671@msgid.xyz","threadId":"65597","inReplyTo":null,"subject":"[PATCH] doc: add caveat about turning off commit-graph","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-05T20:45:42Z","receivedAt":"2026-05-05T20:45:53Z","isPatch":true,"body":"From: Kristoffer Haugsbakk \n\nThe doc `technical/commit-graph.adoc` says that replace objects and\ncommit grafts turn off commit-graph:\n\n Commit grafts and replace objects can change the shape of the commit\n history. The latter can also be enabled/disabled on the fly using\n `--no-replace-objects`. This leads to difficulty storing both possible\n interpretations of a commit id, especially when computing generation\n numbers. The commit-graph will not be read or written when\n replace-objects or grafts are present.\n\nBut this isn’t mentioned in the user-facing doc. Let’s mention it on\ngit-replace(1) and git-commit-graph(1).\n\nSigned-off-by: Kristoffer Haugsbakk \n---\n Documentation/git-commit-graph.adoc | 6 ++++++\n Documentation/git-replace.adoc | 6 ++++++\n 2 files changed, 12 insertions(+)\n\ndiff --git a/Documentation/git-commit-graph.adoc b/Documentation/git-commit-graph.adoc\nindex 6d19026035f..f2a37e91634 100644\n--- a/Documentation/git-commit-graph.adoc\n+++ b/Documentation/git-commit-graph.adoc\n@@ -146,6 +146,12 @@ $ git show-ref -s | git commit-graph write --stdin-commits\n $ git rev-parse HEAD | git commit-graph write --stdin-commits --append\n ------------------------------------------------\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph. See linkgit:git-replace[1].\n+\n CONFIGURATION\n -------------\n \ndiff --git a/Documentation/git-replace.adoc b/Documentation/git-replace.adoc\nindex 0a65460adbd..2c0ea07724d 100644\n--- a/Documentation/git-replace.adoc\n+++ b/Documentation/git-replace.adoc\n@@ -145,6 +145,12 @@ commit instead of the replaced commit.\n There may be other problems when using 'git rev-list' related to\n pending objects.\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph. See linkgit:git-commit-graph[1].\n+\n SEE ALSO\n --------\n linkgit:git-hash-object[1]\n\nbase-commit: 67ad42147a7acc2af6074753ebd03d904476118f\n-- \n2.54.0.13.g9c7419e39f8\n\n"},{"id":"542810","messageId":"5f9f4998-4538-4bc1-a245-4248e18c4e86@gmail.com","threadId":"65597","inReplyTo":"caveat_commit-graph.671@msgid.xyz","subject":"Re: [PATCH] doc: add caveat about turning off commit-graph","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-05-06T13:59:53Z","receivedAt":"2026-05-06T13:59:55Z","isPatch":true,"body":"On 5/5/2026 4:45 PM, kristofferhaugsbakk@fastmail.com wrote:\n> From: Kristoffer Haugsbakk \n> \n> The doc `technical/commit-graph.adoc` says that replace objects and\n> commit grafts turn off commit-graph:\n> \n> Commit grafts and replace objects can change the shape of the commit\n> history. The latter can also be enabled/disabled on the fly using\n> `--no-replace-objects`. This leads to difficulty storing both possible\n> interpretations of a commit id, especially when computing generation\n> numbers. The commit-graph will not be read or written when\n> replace-objects or grafts are present.\n> \n> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n> git-replace(1) and git-commit-graph(1).\n\nI like your initiative to present this incompatibility in the\nuser-facing docs.\n\n> +CAVEATS\n> +-------\n> +\n> +The existence of replace objects or commit grafts turns off reading or\n> +writing to the commit-graph. See linkgit:git-replace[1].\n> +\nThis does seem a little weak. It doesn't really say how this will\nimpact the user. Perhaps we could add something about how performance\nwill likely degrade in this mode?\n\n The existence of replace objects or commit grafts turns off reading or\n writing to the commit-graph, which can cause performance issues. See\n linkgit:git-replace[1].\n\nThanks,\n-Stolee\n"},{"id":"542849","messageId":"3f0e03e4-f1ca-4010-aacf-72b3ce0aebd1@app.fastmail.com","threadId":"65597","inReplyTo":"5f9f4998-4538-4bc1-a245-4248e18c4e86@gmail.com","subject":"Re: [PATCH] doc: add caveat about turning off commit-graph","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-07T14:30:30Z","receivedAt":"2026-05-07T14:30:51Z","isPatch":true,"body":"On Wed, May 6, 2026, at 15:59, Derrick Stolee wrote:\n>>[snip]\n>>\n>> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n>> git-replace(1) and git-commit-graph(1).\n>\n> I like your initiative to present this incompatibility in the\n> user-facing docs.\n>\n>> +CAVEATS\n>> +-------\n>> +\n>> +The existence of replace objects or commit grafts turns off reading or\n>> +writing to the commit-graph. See linkgit:git-replace[1].\n>> +\n> This does seem a little weak. It doesn't really say how this will\n> impact the user. Perhaps we could add something about how performance\n> will likely degrade in this mode?\n>\n> The existence of replace objects or commit grafts turns off reading or\n> writing to the commit-graph, which can cause performance issues. See\n> linkgit:git-replace[1].\n\nThanks, that’s good. But I think this addition makes sense only on\ngit-replace(1). In this (example) git-commit-graph(1) case the whole doc\nalready explains what the commit-graph is about.\n"},{"id":"542863","messageId":"0b67df77-b0c8-47dd-ace5-8dd80474bbe6@gmail.com","threadId":"65597","inReplyTo":"3f0e03e4-f1ca-4010-aacf-72b3ce0aebd1@app.fastmail.com","subject":"Re: [PATCH] doc: add caveat about turning off commit-graph","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-05-07T18:03:52Z","receivedAt":"2026-05-07T18:03:55Z","isPatch":true,"body":"On 5/7/2026 10:30 AM, Kristoffer Haugsbakk wrote:\n> On Wed, May 6, 2026, at 15:59, Derrick Stolee wrote:\n>>> [snip]\n>>>\n>>> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n>>> git-replace(1) and git-commit-graph(1).\n>>\n>> I like your initiative to present this incompatibility in the\n>> user-facing docs.\n>>\n>>> +CAVEATS\n>>> +-------\n>>> +\n>>> +The existence of replace objects or commit grafts turns off reading or\n>>> +writing to the commit-graph. See linkgit:git-replace[1].\n>>> +\n>> This does seem a little weak. It doesn't really say how this will\n>> impact the user. Perhaps we could add something about how performance\n>> will likely degrade in this mode?\n>>\n>> The existence of replace objects or commit grafts turns off reading or\n>> writing to the commit-graph, which can cause performance issues. See\n>> linkgit:git-replace[1].\n> \n> Thanks, that’s good. But I think this addition makes sense only on\n> git-replace(1). In this (example) git-commit-graph(1) case the whole doc\n> already explains what the commit-graph is about.\n\nThat's fair. Thanks!\n-Stolee\n\n"},{"id":"542865","messageId":"V2_caveat_commit-graph.68b@msgid.xyz","threadId":"65597","inReplyTo":"caveat_commit-graph.671@msgid.xyz","subject":"[PATCH v2] doc: add caveat about turning off commit-graph","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-07T18:20:55Z","receivedAt":"2026-05-07T18:21:10Z","isPatch":true,"body":"From: Kristoffer Haugsbakk \n\nThe doc `technical/commit-graph.adoc` says that replace objects and\ncommit grafts turn off commit-graph:\n\n Commit grafts and replace objects can change the shape of the commit\n history. The latter can also be enabled/disabled on the fly using\n `--no-replace-objects`. This leads to difficulty storing both possible\n interpretations of a commit id, especially when computing generation\n numbers. The commit-graph will not be read or written when\n replace-objects or grafts are present.\n\nBut this isn’t mentioned in the user-facing doc. Let’s mention it on\ngit-replace(1) and git-commit-graph(1).\n\nSigned-off-by: Kristoffer Haugsbakk \n---\n\nNotes (series):\n v2: Incorporate “performance issues” suggestion on git-replace(1)\n\n Documentation/git-commit-graph.adoc | 6 ++++++\n Documentation/git-replace.adoc | 7 +++++++\n 2 files changed, 13 insertions(+)\n\ndiff --git a/Documentation/git-commit-graph.adoc b/Documentation/git-commit-graph.adoc\nindex 6d19026035f..f2a37e91634 100644\n--- a/Documentation/git-commit-graph.adoc\n+++ b/Documentation/git-commit-graph.adoc\n@@ -146,6 +146,12 @@ $ git show-ref -s | git commit-graph write --stdin-commits\n $ git rev-parse HEAD | git commit-graph write --stdin-commits --append\n ------------------------------------------------\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph. See linkgit:git-replace[1].\n+\n CONFIGURATION\n -------------\n \ndiff --git a/Documentation/git-replace.adoc b/Documentation/git-replace.adoc\nindex 0a65460adbd..436a0e58caf 100644\n--- a/Documentation/git-replace.adoc\n+++ b/Documentation/git-replace.adoc\n@@ -145,6 +145,13 @@ commit instead of the replaced commit.\n There may be other problems when using 'git rev-list' related to\n pending objects.\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph, which can cause performance issues. See\n+linkgit:git-commit-graph[1].\n+\n SEE ALSO\n --------\n linkgit:git-hash-object[1]\n\nInterdiff against v1:\n diff --git a/Documentation/git-replace.adoc b/Documentation/git-replace.adoc\n index 2c0ea07724d..436a0e58caf 100644\n --- a/Documentation/git-replace.adoc\n +++ b/Documentation/git-replace.adoc\n @@ -149,7 +149,8 @@ CAVEATS\n -------\n \n The existence of replace objects or commit grafts turns off reading or\n -writing to the commit-graph. See linkgit:git-commit-graph[1].\n +writing to the commit-graph, which can cause performance issues. See\n +linkgit:git-commit-graph[1].\n \n SEE ALSO\n --------\n\nbase-commit: 67ad42147a7acc2af6074753ebd03d904476118f\n-- \n2.54.0.13.g9c7419e39f8\n\n"},{"id":"542866","messageId":"913c1338-7745-4229-83fc-cd7a03937d1f@gmail.com","threadId":"65597","inReplyTo":"V2_caveat_commit-graph.68b@msgid.xyz","subject":"Re: [PATCH v2] doc: add caveat about turning off commit-graph","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-05-07T18:59:16Z","receivedAt":"2026-05-07T18:59:18Z","isPatch":true,"body":"On 5/7/2026 2:20 PM, kristofferhaugsbakk@fastmail.com wrote:\n> From: Kristoffer Haugsbakk \n> \n> The doc `technical/commit-graph.adoc` says that replace objects and\n> commit grafts turn off commit-graph:\n> \n> Commit grafts and replace objects can change the shape of the commit\n> history. The latter can also be enabled/disabled on the fly using\n> `--no-replace-objects`. This leads to difficulty storing both possible\n> interpretations of a commit id, especially when computing generation\n> numbers. The commit-graph will not be read or written when\n> replace-objects or grafts are present.\n> \n> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n> git-replace(1) and git-commit-graph(1).\n...\n> Interdiff against v1:\n> diff --git a/Documentation/git-replace.adoc b/Documentation/git-replace.adoc\n> index 2c0ea07724d..436a0e58caf 100644\n> --- a/Documentation/git-replace.adoc\n> +++ b/Documentation/git-replace.adoc\n> @@ -149,7 +149,8 @@ CAVEATS\n> -------\n> \n> The existence of replace objects or commit grafts turns off reading or\n> -writing to the commit-graph. See linkgit:git-commit-graph[1].\n> +writing to the commit-graph, which can cause performance issues. See\n> +linkgit:git-commit-graph[1].\nThanks for the update! LGTM.\n\n-Stolee\n"},{"id":"542873","messageId":"V3_caveat_commit-graph.6b6@msgid.xyz","threadId":"65597","inReplyTo":"V2_caveat_commit-graph.68b@msgid.xyz","subject":"[PATCH v3] doc: add caveat about turning off commit-graph","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-07T19:42:28Z","receivedAt":"2026-05-07T19:42:43Z","isPatch":true,"body":"From: Kristoffer Haugsbakk \n\nThe doc `technical/commit-graph.adoc` says that replace objects and\ncommit grafts turn off commit-graph:\n\n Commit grafts and replace objects can change the shape of the commit\n history. The latter can also be enabled/disabled on the fly using\n `--no-replace-objects`. This leads to difficulty storing both possible\n interpretations of a commit id, especially when computing generation\n numbers. The commit-graph will not be read or written when\n replace-objects or grafts are present.\n\nBut this isn’t mentioned in the user-facing doc. Let’s mention it on\ngit-replace(1) and git-commit-graph(1).\n\nAcked-by: Derrick Stolee \nSigned-off-by: Kristoffer Haugsbakk \n---\n\nNotes (series):\n v3: Add Ack\n v2: Incorporate “performance issues” suggestion on git-replace(1)\n\n Documentation/git-commit-graph.adoc | 6 ++++++\n Documentation/git-replace.adoc | 7 +++++++\n 2 files changed, 13 insertions(+)\n\ndiff --git a/Documentation/git-commit-graph.adoc b/Documentation/git-commit-graph.adoc\nindex 6d19026035f..f2a37e91634 100644\n--- a/Documentation/git-commit-graph.adoc\n+++ b/Documentation/git-commit-graph.adoc\n@@ -146,6 +146,12 @@ $ git show-ref -s | git commit-graph write --stdin-commits\n $ git rev-parse HEAD | git commit-graph write --stdin-commits --append\n ------------------------------------------------\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph. See linkgit:git-replace[1].\n+\n CONFIGURATION\n -------------\n \ndiff --git a/Documentation/git-replace.adoc b/Documentation/git-replace.adoc\nindex 0a65460adbd..436a0e58caf 100644\n--- a/Documentation/git-replace.adoc\n+++ b/Documentation/git-replace.adoc\n@@ -145,6 +145,13 @@ commit instead of the replaced commit.\n There may be other problems when using 'git rev-list' related to\n pending objects.\n \n+CAVEATS\n+-------\n+\n+The existence of replace objects or commit grafts turns off reading or\n+writing to the commit-graph, which can cause performance issues. See\n+linkgit:git-commit-graph[1].\n+\n SEE ALSO\n --------\n linkgit:git-hash-object[1]\n\nInterdiff against v2:\n\nRange-diff against v2:\n1: 82faa72f7bf ! 1: fb5ba74ea3e doc: add caveat about turning off commit-graph\n @@ Commit message\n But this isn’t mentioned in the user-facing doc. Let’s mention it on\n git-replace(1) and git-commit-graph(1).\n \n + Acked-by: Derrick Stolee \n Signed-off-by: Kristoffer Haugsbakk \n \n ## Documentation/git-commit-graph.adoc ##\n\nbase-commit: 67ad42147a7acc2af6074753ebd03d904476118f\n-- \n2.54.0.13.g9c7419e39f8\n\n"},{"id":"542874","messageId":"39f029d7-0c12-4a79-a701-04abf82cfde8@gmail.com","threadId":"65597","inReplyTo":"V3_caveat_commit-graph.6b6@msgid.xyz","subject":"Re: [PATCH v3] doc: add caveat about turning off commit-graph","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-05-07T19:56:39Z","receivedAt":"2026-05-07T19:56:41Z","isPatch":true,"body":"On 5/7/2026 3:42 PM, kristofferhaugsbakk@fastmail.com wrote:\n> From: Kristoffer Haugsbakk \n\n> Range-diff against v2:\n> 1: 82faa72f7bf ! 1: fb5ba74ea3e doc: add caveat about turning off commit-graph\n> @@ Commit message\n> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n> git-replace(1) and git-commit-graph(1).\n> \n> + Acked-by: Derrick Stolee \n> Signed-off-by: Kristoffer Haugsbakk \n> \n> ## Documentation/git-commit-graph.adoc ##\nIn general, you don't need to do this. Junio will add these\nduring his application of the series, if necessary.\n\nThanks,\n-Stolee\n\n"},{"id":"542878","messageId":"7eae7ad5-5b09-4069-aafe-571f3e345b83@app.fastmail.com","threadId":"65597","inReplyTo":"39f029d7-0c12-4a79-a701-04abf82cfde8@gmail.com","subject":"Re: [PATCH v3] doc: add caveat about turning off commit-graph","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-07T21:14:27Z","receivedAt":"2026-05-07T21:14:49Z","isPatch":true,"body":"On Thu, May 7, 2026, at 21:56, Derrick Stolee wrote:\n> On 5/7/2026 3:42 PM, kristofferhaugsbakk@fastmail.com wrote:\n>> From: Kristoffer Haugsbakk \n>\n>> Range-diff against v2:\n>> 1: 82faa72f7bf ! 1: fb5ba74ea3e doc: add caveat about turning off commit-graph\n>> @@ Commit message\n>> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n>> git-replace(1) and git-commit-graph(1).\n>>\n>> + Acked-by: Derrick Stolee \n>> Signed-off-by: Kristoffer Haugsbakk \n>>\n>> ## Documentation/git-commit-graph.adoc ##\n> In general, you don't need to do this. Junio will add these\n> during his application of the series, if necessary.\n\nIt’s certainly not necessary, yeah. :)\n\nI am basing this on a recollection of someone quoting this from\nSubmittingPatches:\n\n Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n `Tested-by:` lines as necessary to credit people who helped your\n patch, and \"cc:\" them when sending such a final version for inclusion.\n\nThey said that this was outdated since Junio does it himself. But then\nJunio replied and said that it’s good/better if the contributor does it.\n\nI’m terrible at finding back to conversations from more than six months\nago, but it might have been this one:[1]\n\n >> +Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n >> +`Tested-by:` lines as necessary to credit people who helped your\n >> +patch, and \"cc:\" them when sending such a final version for inclusion.\n >\n > Again, not a new problem introduced by this patch, but it seems like\n > all of these are actively wrong. In every case, these trailers are\n > _given_ by reviewers _after_ a series has been submitted (thus, too\n > late for the author to add them), ...\n\n Well, this is another instance that I may be trying to be too\n helpful and over extending myself, which does not make the process\n scale well (the other one being the \"one final resend after the\n list reached a consensus\").\n\n If the authors collect Acks and Reviewed-by's and resend after the\n list reached the concensus, it may take one extra iteration, but I\n no longer have to keep track of these trailers myself, which could\n be a big win.\n\n So, I dunno.\n\nIn conclusion for now: I dunno. :)\n\n† 1: https://lore.kernel.org/git/xmqqo7aiyrxl.fsf@gitster.g/#t\n\nI won’t rush to resubmit over adding a trailer if I know the maintainer\nmight have already applied the patch. But seeing as how he’s more or\nless away-from-inbox right now I figured he won’t beat me to it.\n"},{"id":"542995","messageId":"xmqq8q9qwxrr.fsf@gitster.g","threadId":"65597","inReplyTo":"7eae7ad5-5b09-4069-aafe-571f3e345b83@app.fastmail.com","subject":"Re: [PATCH v3] doc: add caveat about turning off commit-graph","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-05-11T01:16:56Z","receivedAt":"2026-05-11T01:16:59Z","isPatch":true,"body":"\"Kristoffer Haugsbakk\" writes:\n\n> On Thu, May 7, 2026, at 21:56, Derrick Stolee wrote:\n>> On 5/7/2026 3:42 PM, kristofferhaugsbakk@fastmail.com wrote:\n>>> From: Kristoffer Haugsbakk \n>>\n>>> Range-diff against v2:\n>>> 1: 82faa72f7bf ! 1: fb5ba74ea3e doc: add caveat about turning off commit-graph\n>>> @@ Commit message\n>>> But this isn’t mentioned in the user-facing doc. Let’s mention it on\n>>> git-replace(1) and git-commit-graph(1).\n>>>\n>>> + Acked-by: Derrick Stolee \n>>> Signed-off-by: Kristoffer Haugsbakk \n>>>\n>>> ## Documentation/git-commit-graph.adoc ##\n>> In general, you don't need to do this. Junio will add these\n>> during his application of the series, if necessary.\n>\n> It’s certainly not necessary, yeah. :)\n>\n> I am basing this on a recollection of someone quoting this from\n> SubmittingPatches:\n>\n> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n> `Tested-by:` lines as necessary to credit people who helped your\n> patch, and \"cc:\" them when sending such a final version for inclusion.\n>\n> They said that this was outdated since Junio does it himself. But then\n> Junio replied and said that it’s good/better if the contributor does it.\n\nI used to say \"let me do this to skip one extra roundtrip\" but I\nstopped saying so. Perhaps I should be a bit more explicit and stop\nbeing silently nice to contributors who do not follow the guidelines\nto the letter in order to unconfuse you and your friends. It\nactually is a tempting thought.\n\n> Well, this is another instance that I may be trying to be too\n> helpful and over extending myself, which does not make the process\n> scale well (the other one being the \"one final resend after the\n> list reached a consensus\").\n>\n> If the authors collect Acks and Reviewed-by's and resend after the\n> list reached the concensus, it may take one extra iteration, but I\n> no longer have to keep track of these trailers myself, which could\n> be a big win.\n>\n> So, I dunno.\n>\n> In conclusion for now: I dunno. :)\n\nI do not know either, but if we agree that everybody should do so\nthemselves and I should refrain from applying the ones that lack\nAcks, I can adjust. There will be lot of unapplied patches left on\nthe mailing list initially until the contributors adjust their\nbehaviour, but in the long run it may be beneficial? \n"},{"id":"543031","messageId":"agGTcTZip0KItj1v@ugly.lan","threadId":"65597","inReplyTo":"xmqq8q9qwxrr.fsf@gitster.g","subject":"Re: [PATCH v3] doc: add caveat about turning off commit-graph","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2026-05-11T08:29:37Z","receivedAt":"2026-05-11T08:29:42Z","isPatch":true,"body":"On Mon, May 11, 2026 at 10:16:56AM +0900, Junio C Hamano wrote:\n>There will be lot of unapplied patches left on the mailing list \n>initially until the contributors adjust their behaviour,\n\n>but in the long run it may be beneficial? \n>\nno, it won't, because \"the contributors\" doesn't have a collective mind \nbeyond the core group.\n\nevery bit of bureaucracy you add just leads to fewer successful (and \nsubsequently attempted repeat) contributions.\n\nif the scalability problems with making things contributor-friendly are \ntoo much for you, then rethink the process/tooling. i've already made my \ncase for gerrit [1] ...\n\n[1] https://lore.kernel.org/git/ZcA0NEb+lnjeZUBe@ugly/\n"},{"id":"543739","messageId":"344cc7d8-4ab3-40f4-9564-80e5888c5bc9@app.fastmail.com","threadId":"65597","inReplyTo":"xmqq8q9qwxrr.fsf@gitster.g","subject":"Re: [PATCH v3] doc: add caveat about turning off commit-graph","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-05-20T07:10:54Z","receivedAt":"2026-05-20T07:11:16Z","isPatch":true,"body":"On Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:\n>>>[snip]\n>>\n>> It’s certainly not necessary, yeah. :)\n>>\n>> I am basing this on a recollection of someone quoting this from\n>> SubmittingPatches:\n>>\n>> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n>> `Tested-by:` lines as necessary to credit people who helped your\n>> patch, and \"cc:\" them when sending such a final version for inclusion.\n>>\n>> They said that this was outdated since Junio does it himself. But then\n>> Junio replied and said that it’s good/better if the contributor does it.\n>\n> I used to say \"let me do this to skip one extra roundtrip\" but I\n> stopped saying so. Perhaps I should be a bit more explicit and stop\n> being silently nice to contributors who do not follow the guidelines\n> to the letter in order to unconfuse you and your friends. It\n> actually is a tempting thought.\n\nI am personally okay with adding these trailers and think it’s nice to\ndocument such review/ack/etc. interactions.\n\nJust considering this part in isolation, I imagine that you not filling\nin missing acks etc. will lead to less such trailers because (1) most\ncontributors don’t seem to follow up with such updates if the only\nchange is the trailers section, and (2) most people here (culturally)\ndon’t add explicit trailer lines in their replies (e.g. an “LGTM” is\nclearly an ack, but not explicit).\n\n>> Well, this is another instance that I may be trying to be too\n>> helpful and over extending myself, which does not make the process\n>> scale well (the other one being the \"one final resend after the\n>> list reached a consensus\").\n>>\n>> If the authors collect Acks and Reviewed-by's and resend after the\n>> list reached the concensus, it may take one extra iteration, but I\n>> no longer have to keep track of these trailers myself, which couldOn Mon, May 11, 2026, at 03:16, Junio C Hamano wrote:\n>>>[snip]\n>>\n>> It’s certainly not necessary, yeah. :)\n>>\n>> I am basing this on a recollection of someone quoting this from\n>> SubmittingPatches:\n>>\n>> Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and\n>> `Tested-by:` lines as necessary to credit people who helped your\n>> patch, and \"cc:\" them when sending such a final version for inclusion.\n>>\n>> They said that this was outdated since Junio does it himself. But then\n>> Junio replied and said that it’s good/better if the contributor does it.\n>\n> I used to say \"let me do this to skip one extra roundtrip\" but I\n> stopped saying so. Perhaps I should be a bit more explicit and stop\n> being silently nice to contributors who do not follow the guidelines\n> to the letter in order to unconfuse you and your friends. It\n> actually is a tempting thought.\n\nI am personally okay with adding these trailers and think it’s nice to\ndocument such review/ack/etc. interactions.\n\nJust considering this part in isolation, I imagine that you not filling\nin missing acks etc. will lead to less such trailers because (1) most\ncontributors don’t seem to follow up with such updates if the only\nchange is the trailers section, and (2) most people here (culturally)\ndon’t add explicit trailer lines in their replies (e.g. an “LGTM” is\nclearly an ack, but not explicit).\n\n>> Well, this is another instance that I may be trying to be too\n>> helpful and over extending myself, which does not make the process\n>> scale well (the other one being the \"one final resend after the\n>> list reached a consensus\").\n>>\n>> If the authors collect Acks and Reviewed-by's and resend after the\n>> list reached the concensus, it may take one extra iteration, but I\n>> no longer have to keep track of these trailers myself, which could\n>> be a big win.\n>>\n>> So, I dunno.\n>>\n>> In conclusion for now: I dunno. :)\n>\n> I do not know either, but if we agree that everybody should do so\n> themselves and I should refrain from applying the ones that lack\n> Acks, I can adjust. There will be lot of unapplied patches left on\n> the mailing list initially until the contributors adjust their\n> behaviour, but in the long run it may be beneficial?\n\nOkay, if the proposal is to *not* e.g. graduate series to `next` that\nhaven’t applied the acks etc. then I understand how it will likely lead\nto some stalls until people adjust.\n\nTo be clear, I imagine this is how it would play out:\n\n• The series in itself is ready for `next` and has no unapplied acks\n etc.: it graduates to `next`\n• The series in itself is ready for `next` but has unapplied acks etc.:\n it does not graduate to `next` since the contributor should send a new\n version with the trailer changes\n\n***\n\nThere is also the paragraph previous to the trailer one:\n\n After the list reached a consensus that it is a good idea to apply the\n patch, re-send it with \"To:\" set to the maintainer{current-maintainer}\n and \"cc:\" the list{git-ml} for inclusion. This is especially relevant\n when the maintainer did not heavily participate in the discussion and\n instead left the review to trusted others.\n\n Do not forget to add trailers such as `Acked-by:`, [...]\n\nAnd I have only managed to follow that part maybe, probably one single time.\n\n>> be a big win.\n>>\n>> So, I dunno.\n>>\n>> In conclusion for now: I dunno. :)\n>\n> I do not know either, but if we agree that everybody should do so\n> themselves and I should refrain from applying the ones that lack\n> Acks, I can adjust. There will be lot of unapplied patches left on\n> the mailing list initially until the contributors adjust their\n> behaviour, but in the long run it may be beneficial?\n\nOkay, if the proposal is to *not* e.g. graduate series to `next` that\nhaven’t applied the acks etc. then I understand how it will likely lead\nto some stalls until people adjust.\n\nTo be clear, I imagine this is how it would play out:\n\n• The series in itself is ready for `next` and has no unapplied acks\n etc.: it graduates to `next`\n• The series in itself is ready for `next` but has unapplied acks etc.:\n it does not graduate to `next` since the contributor should send a new\n version with the trailer changes\n\n***\n\nThere is also the paragraph previous to the trailer one:\n\n After the list reached a consensus that it is a good idea to apply the\n patch, re-send it with \"To:\" set to the maintainer{current-maintainer}\n and \"cc:\" the list{git-ml} for inclusion. This is especially relevant\n when the maintainer did not heavily participate in the discussion and\n instead left the review to trusted others.\n\n Do not forget to add trailers such as `Acked-by:`, [...]\n\nAnd I have only managed to follow that part maybe, probably one single time.\n"}]}