{"thread":{"id":"62201","subject":"How dangerous is --committer-date-is-author-date these days?","startedAt":"2024-09-28T07:33:42Z","lastAt":"2025-11-27T06:30:34Z","messageCount":25,"participants":["Johannes Sixt","Phillip Wood","Kristoffer Haugsbakk","Junio C Hamano","kristofferhaugsbakk@fastmail.com","SZEDER Gábor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"503627","messageId":"6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org","threadId":"62201","inReplyTo":null,"subject":"How dangerous is --committer-date-is-author-date these days?","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-09-28T06:59:57Z","receivedAt":"2024-09-28T07:33:42Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"The option --committer-date-is-author-date of git-rebase rewrites the\ncommitter dates like its name suggests. It is not uncommon that commits\nare rearranged and cherry-picked. Then, as a consequence, author dates\nare not decreasing when walking back in history. Now, if such a history\nwith a non-monotonic author date is rebased one final time with\n--committer-date-is-author-date, this creates a history with\nnon-monotonic committer dates. I recall that this is not a good thing to\nhave since it can confuse our history walker.\n\n- Why do we have --committer-date-is-author-date in a porcelain command?\n- Should we remove it?\n- Should we require an explicit --force instead of implying it?\n- Should we issue a big warning about the consequences?\n\nHere is the discussion that introduced the option git-rebase:\nrebase -i: support --committer-date-is-author-date\nhttps://lore.kernel.org/git/20200817174004.92455-4-phillip.wood123@gmail.com/\n\nI am asking this here after I have participated in this Stackoverflow\nquestion, where git rebase --committer-date-is-author-date was suggested\nas a solution to \"rewrite name and email, but not timestamps\".\nhttps://stackoverflow.com/questions/79024409\n\n-- Hannes\n"},{"id":"503628","messageId":"aa981bb7-dd3b-4e63-9769-0fc2559983e6@gmail.com","threadId":"62201","inReplyTo":"6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org","subject":"Re: How dangerous is --committer-date-is-author-date these days?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-28T09:49:17Z","receivedAt":"2024-09-28T09:49:24Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Johannes\n\nOn 28/09/2024 07:59, Johannes Sixt wrote:\n> The option --committer-date-is-author-date of git-rebase rewrites the\n> committer dates like its name suggests. It is not uncommon that commits\n> are rearranged and cherry-picked. Then, as a consequence, author dates\n> are not decreasing when walking back in history. Now, if such a history\n> with a non-monotonic author date is rebased one final time with\n> --committer-date-is-author-date, this creates a history with\n> non-monotonic committer dates. I recall that this is not a good thing to\n> have since it can confuse our history walker.\n> \n> - Why do we have --committer-date-is-author-date in a porcelain command?\n\nSupport was added to the sequencer to reduce the differences between the \ntwo rebase backends in the hope that one day we'll be able to remove the \napply based backend. Support was added to the shell based rebase in \n570ccad33e (rebase: add options passed to git-am, 2009-03-18), there is \nnot much discussion in the commit message or mailing list thread [1] \nabout the motivation for adding this support.\n\n[1] \nhttps://lore.kernel.org/git/1237409629-4289-1-git-send-email-barra_cuda@katamail.com/\n\n> - Should we remove it?\n\nIt is only a problem when re-arranging commits - even then I think the \ncommit walk machinery has some tolerance to commit dates that do not \nincrease monotonically in order accommodate clocks that are out of sync. \nIt is perfectly fine for non-interactive rebases (or just squashing \nfixups) so removing it seems like throwing out the baby with the bathwater.\n\n> - Should we require an explicit --force instead of implying it?\n\nI think we'd want a convincing reason to change the behavior - the other \noptions that require the history to be rewritten all imply \"--force\" \nrather than requiring the user to pass it separately.\n\n> - Should we issue a big warning about the consequences?\n\nIt would certainly be worth adding a warning to the documentation. To \nissue a warning at run-time would require us to check that the commits \nare actually being re-arranged as there are plenty of reasons to use \n\"--interactive\" without changing the order of commits.\n\nBest Wishes\n\nPhillip\n"},{"id":"503630","messageId":"6d6b2ff0-b4e4-4442-a3be-9b31742db280@gmail.com","threadId":"62201","inReplyTo":"aa981bb7-dd3b-4e63-9769-0fc2559983e6@gmail.com","subject":"Re: How dangerous is --committer-date-is-author-date these days?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-09-28T10:04:01Z","receivedAt":"2024-09-28T10:04:10Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 28/09/2024 10:49, Phillip Wood wrote:\n>> - Should we remove it?\n> \n> It is only a problem when re-arranging commits \n\nOf course it's also a problem if one is rebasing onto a commit that is \nnewer than the commits that are being rebased. That makes it more of a \nconcern, though the option has existed since 2009 and I don't recall \nanyone complaining about the effects of using it. We should certainly \nspell out the potential problems in the documentation.\n\nBest Wishes\n\nPhillip\n"},{"id":"503734","messageId":"93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com","threadId":"62201","inReplyTo":"6d6b2ff0-b4e4-4442-a3be-9b31742db280@gmail.com","subject":"Re: How dangerous is --committer-date-is-author-date these days?","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-09-30T14:49:32Z","receivedAt":"2024-09-30T14:49:55Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"As a Git user, I don’t understand why some people want to fiddle with\nthis field in rewrite operations. It’s very hidden (apparently you have\nto use something like `git log --format=fuller` to reveal it).\n\nI can’t speak for power users. But regular users? Well I see questions\nabout being very deliberate about setting this field on rewrite\noperations on StackOverflow (at least one time). But I can only guess\n*why* they are particular about it (this part is often not explained).\nAnd I don’t know if they know the true “spirit” behind the field.\nMaybe they are of the impression that committer date and author date\n*ought to* be the same?\n\nOf course the aforementioned patch by Philip[1] was done in order to\nmake the available options between the two rebase backends consistent.\nThis option `--committer-date-is-author-date` was first added in\n3f01ad66549 (am: Add --committer-date-is-author-date option,\n2009-01-22). The email that I could find[2] for the patch has no\nfollow-up replies.\n\nThat option was added to git-am(1). So not a rewrite operation. Rather\na “lie” (as it was documented on that commit).\n\nWhich ties me back to the “regular user” point: most people don’t use\nemail workflows. So adding commits from email is not something they do.\nSurely most uses of this option is in git-rebase(1). And most users\nmight take for a given that author=committer. In turn also that\ncommitter-date=author-date.\n\nAgain for those who care enough to hunt down this long (words) option.\n\n🔗 1: https://lore.kernel.org/git/20200817174004.92455-4-phillip.wood123@gmail.com/\n🔗 2: https://lore.kernel.org/git/20090124101750.6117@nanako3.lavabit.com/\n\n-- \nKristoffer Haugsbakk\n"},{"id":"503744","messageId":"xmqqwmit83y0.fsf@gitster.g","threadId":"62201","inReplyTo":"93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com","subject":"Re: How dangerous is --committer-date-is-author-date these days?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-09-30T17:08:23Z","receivedAt":"2024-09-30T17:08:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> As a Git user, I don’t understand why some people want to fiddle with\n> this field in rewrite operations. It’s very hidden (apparently you have\n> to use something like `git log --format=fuller` to reveal it).\n\nFWIW, as a Git user, I don't, either.\n\nIt is justifiable for \"rebase -i\" to be aware of the option, merely\nbecause the underlying \"git am\" had it. I think \"--ignore-date\"\noption falls into a similar bucket, but it is of lessor evil between\nthe two (at least I can see a legitimate reasoning behind use of\nthat option).\n\n> I can’t speak for power users. But regular users? Well I see questions\n> about being very deliberate about setting this field on rewrite\n> operations on StackOverflow (at least one time). But I can only guess\n> *why* they are particular about it (this part is often not explained).\n> And I don’t know if they know the true “spirit” behind the field.\n\nVery nicely said. There _might_ be a legitimate reason to futz with\nthe committer date, but I do not think of a good reason why it makes\nsense to replace it with the author date. They are separate fields\nbecause they mean different things---your mention of \"true spirit\"\nis spot-on.\n\n> That option was added to git-am(1). So not a rewrite operation. Rather\n> a “lie” (as it was documented on that commit).\n\nYes, I do not offhand see a reason why the option should exist. I\nwon't be the person who says \"no, it is valuable, do not touch it\"\nif somebody proposes to drop it (from all places) at a major version\nboundary.\n\nThanks.\n\n"},{"id":"528300","messageId":"d17060d9b72.1759952528.git.code@khaugsbakk.name","threadId":"62201","inReplyTo":"6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org","subject":"[PATCH] doc: warn against --committer-date-is-author-date","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-08T19:45:20Z","receivedAt":"2025-10-08T19:45:30Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"From: Kristoffer Haugsbakk \n\nThis option has legitimate uses but could create a commit history which\nviolates the assumption that commits are strictly increasing in terms of\ncommit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n\n❦\n\nThe genesis of this option is 3f01ad66 (am: Add --committer-date-is-\nauthor-date option, 2009-01-22). The commit message doesn’t give us an\nexample of a use case, but the thread starter does:[1]\n\n I've a big set of patches in a mbox file: there's sufficient info\n inside for git-am to work.\n\n Yet, each time I do import these, my sha1sums are changing because of\n different commit dates.\n\n I'd like to force the commit date to match the info/date from the time\n I received the email (and therefore always get back the right\n sha1sums).\n\nSo the motivation was to treat git-am(1) as an import command that\ncreates the same commit IDs given the same base and committer.\n\n[1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n\nSuggested-by: Johannes Sixt \nSigned-off-by: Kristoffer Haugsbakk \n---\n\nNotes (series):\n Topic name: kh/committer-author-date\n \n Topic summary: \"--committer-date-is-author-date\" can create a history\n with commit timestamps that are not strictly increasing. That doesn't\n play well with the revision walking machinery. Warn against that.\n \n (See https://lore.kernel.org/git/cover.1759873165.git.me@ttaylorr.com/ )\n \n -----\n \n I thought about marking it as deprecated but eventually found out why it\n was added. And it wasn’t for some (still unknown) dedication or\n not-explained *want* to keep the committer date and author date in synch\n just-because (as I thought[1]).\n \n Hannes asked[2] why it is a porcelain option? (You can after all script\n the same behavior with a little effort.) Personally I think the Git\n porcelain is not shy about providing facilities for crafting made-up\n histories to its users. And I personally think that’s a good thing.\n \n This does seem to indicate that this option doesn’t make much sense for\n git-rebase(1) though, no? Given that it will `--force-rebase`, i.e. will\n force new commit IDs.\n \n 🔗 1: https://lore.kernel.org/git/93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com/\n 🔗 2: https://lore.kernel.org/git/6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org/\n\n Documentation/git-am.adoc | 17 ++++++++++++-----\n Documentation/git-rebase.adoc | 14 +++++++++++---\n 2 files changed, 23 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\nindex 221070de481..c36ae679cfb 100644\n--- a/Documentation/git-am.adoc\n+++ b/Documentation/git-am.adoc\n@@ -156,11 +156,18 @@ Valid for the `--whitespace` option are:\n \tSee also linkgit:githooks[5].\n \n --committer-date-is-author-date::\n-\tBy default the command records the date from the e-mail\n-\tmessage as the commit author date, and uses the time of\n-\tcommit creation as the committer date. This allows the\n-\tuser to lie about the committer date by using the same\n-\tvalue as the author date.\n+\tNOTE: The history walking machinery assumes that commits have\n+\tstrictly increasing commit timestamps, with some tolerance for\n+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n+\tthis option to lie about the committer date when applying\n+\tcommits on top of a base which commit is older (in terms of the\n+\tcommit date) than the oldest patch you are applying.\n++\n+By default the command records the date from the e-mail\n+message as the commit author date, and uses the time of\n+commit creation as the committer date. This allows the\n+user to lie about the committer date by using the same\n+value as the author date.\n \n --ignore-date::\n \tBy default the command records the date from the e-mail\ndiff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\nindex 956d3048f5a..336ee90f7e3 100644\n--- a/Documentation/git-rebase.adoc\n+++ b/Documentation/git-rebase.adoc\n@@ -504,9 +504,17 @@ merge backend;;\n See also INCOMPATIBLE OPTIONS below.\n \n --committer-date-is-author-date::\n-\tInstead of using the current time as the committer date, use\n-\tthe author date of the commit being rebased as the committer\n-\tdate. This option implies `--force-rebase`.\n+\tNOTE: The history walking machinery assumes that commits have\n+\tstrictly increasing commit timestamps, with some tolerance for\n+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n+\tthis option to lie about the committer date when applying\n+\tcommits on top of a base which commit is older (in terms of the\n+\tcommit date) than the oldest commit you are applying (in\n+\tterms of the author date).\n++\n+Instead of using the current time as the committer date, use\n+the author date of the commit being rebased as the committer\n+date. This option implies `--force-rebase`.\n \n --ignore-date::\n --reset-author-date::\n\nbase-commit: c44beea485f0f2feaf460e2ac87fdd5608d63cf0\n-- \n2.51.0.352.g356bc2d8d49\n\n"},{"id":"528308","messageId":"aObMc2GV8fAE9IX2@szeder.dev","threadId":"62201","inReplyTo":"93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com","subject":"Re: How dangerous is --committer-date-is-author-date these days?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2025-10-08T20:41:23Z","receivedAt":"2025-10-08T20:41:27Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Sep 30, 2024 at 04:49:32PM +0200, Kristoffer Haugsbakk wrote:\n> As a Git user, I don’t understand why some people want to fiddle with\n> this field in rewrite operations. It’s very hidden (apparently you have\n> to use something like `git log --format=fuller` to reveal it).\n\nFWIW, GitHub and similar sites display only the committer date.\n\n> I can’t speak for power users. But regular users? Well I see questions\n> about being very deliberate about setting this field on rewrite\n> operations on StackOverflow (at least one time). But I can only guess\n> *why* they are particular about it (this part is often not explained).\n\nPerhaps they prefer to see the author date even on GitHub, and try to\nwork around its shortcomings.\n\n"},{"id":"528391","messageId":"3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com","threadId":"62201","inReplyTo":"d17060d9b72.1759952528.git.code@khaugsbakk.name","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-10-09T13:46:41Z","receivedAt":"2025-10-09T13:46:46Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Kristoffer\n\nOn 08/10/2025 20:45, kristofferhaugsbakk@fastmail.com wrote:\n> From: Kristoffer Haugsbakk \n> \n> This option has legitimate uses but could create a commit history which\n> violates the assumption that commits are strictly increasing in terms of\n> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n> \n> ❦\n\nWhat's this?\n\n> The genesis of this option is 3f01ad66 (am: Add --committer-date-is-\n> author-date option, 2009-01-22). The commit message doesn’t give us an\n> example of a use case, but the thread starter does:[1]\n> \n> I've a big set of patches in a mbox file: there's sufficient info\n> inside for git-am to work.\n> \n> Yet, each time I do import these, my sha1sums are changing because of\n> different commit dates.\n> \n> I'd like to force the commit date to match the info/date from the time\n> I received the email (and therefore always get back the right\n> sha1sums).\n> \n> So the motivation was to treat git-am(1) as an import command that\n> creates the same commit IDs given the same base and committer.\n\nThat seems like a reasonable thing for \"git am\" to do. I'd be interested \nto know what the rationale was for adding it to \"git rebase\". In \nretrospect I feel it was a mistake to port this option over to the \nsequencer just to match what the am based rebase did.>\n> [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n> \n> I thought about marking it as deprecated but eventually found out why it\n> was added. And it wasn’t for some (still unknown) dedication or\n> not-explained *want* to keep the committer date and author date in synch\n> just-because (as I thought[1]).\n\nWe should maybe think about deprecating it for \"git rebase\" though as it \nis a lot less clear that it is sensible there. If you're rebasing a \nbranch then there is a very high likely hood that the upstream committer \ndates of the commits the branch is being rebased onto will be newer that \nthe author dates of the commits in your branch.\n\nI've left a couple of comments below\n> diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n> index 221070de481..c36ae679cfb 100644\n> --- a/Documentation/git-am.adoc\n> +++ b/Documentation/git-am.adoc\n> @@ -156,11 +156,18 @@ Valid for the `--whitespace` option are:\n> \tSee also linkgit:githooks[5].\n> \n> --committer-date-is-author-date::\n> -\tBy default the command records the date from the e-mail\n> -\tmessage as the commit author date, and uses the time of\n> -\tcommit creation as the committer date. This allows the\n> -\tuser to lie about the committer date by using the same\n> -\tvalue as the author date.\n> +\tNOTE: The history walking machinery assumes that commits have\n> +\tstrictly increasing commit timestamps, with some tolerance for\n> +\tclock skew (see linkgit:git-rev-list[1]).\n\nIs there a particuaar section of the rev-list man page you had in mind \nhere? I had a quick look and I couldn't see anything about clock skew.\n\n> You should only use\n> +\tthis option to lie about the committer date when applying\n\ns/lie/override/ ?\n\n> +\tcommits on top of a base which commit is older (in terms of the\n> +\tcommit date) than the oldest patch you are applying.\n> ++\n> +By default the command records the date from the e-mail\n> +message as the commit author date, and uses the time of\n> +commit creation as the committer date. This allows the\n> +user to lie about the committer date by using the same\n> +value as the author date.\n> \n> --ignore-date::\n> \tBy default the command records the date from the e-mail\n> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n> index 956d3048f5a..336ee90f7e3 100644\n> --- a/Documentation/git-rebase.adoc\n> +++ b/Documentation/git-rebase.adoc\n> @@ -504,9 +504,17 @@ merge backend;;\n> See also INCOMPATIBLE OPTIONS below.\n> \n> --committer-date-is-author-date::\n> -\tInstead of using the current time as the committer date, use\n> -\tthe author date of the commit being rebased as the committer\n> -\tdate. This option implies `--force-rebase`.\n> +\tNOTE: The history walking machinery assumes that commits have\n> +\tstrictly increasing commit timestamps, with some tolerance for\n> +\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> +\tthis option to lie about the committer date when applying\n> +\tcommits on top of a base which commit is older (in terms of the\n\nThe comments above apply here as well. In addition s/applying \ncommits/rebasing commits/ for this command I think.\n\n> +\tcommit date) than the oldest commit you are applying (in\n> +\tterms of the author date).\n\nWe should also warn against using this option when rearranging commits \nwith \"git rebase -i\" as well.\n\nThanks for working on this, it is a very good idea to add a warning to \nthe documentation for this option. I'm going to be off the list for the \nnext 10 days or so, I'll look at any re-roll when I return.\n\nThanks\n\nPhillip\n\n"},{"id":"528393","messageId":"aae39545-461a-44f0-b01f-bb40b53b1858@app.fastmail.com","threadId":"62201","inReplyTo":"3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-09T14:31:40Z","receivedAt":"2025-10-09T14:32:02Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 9, 2025, at 15:46, Phillip Wood wrote:\n> On 08/10/2025 20:45, kristofferhaugsbakk@fastmail.com wrote:\n>>[snip]\n>>\n>> ❦\n>\n> What's this?\n\nA thematic break.\n\n>\n>> The genesis of this option is 3f01ad66 (am: Add --committer-date-is-\n>> author-date option, 2009-01-22). The commit message doesn’t give us an\n>> example of a use case, but the thread starter does:[1]\n>>\n>>[snip quote]\n>>\n>> So the motivation was to treat git-am(1) as an import command that\n>> creates the same commit IDs given the same base and committer.\n>\n> That seems like a reasonable thing for \"git am\" to do. I'd be interested\n> to know what the rationale was for adding it to \"git rebase\". In\n> retrospect I feel it was a mistake to port this option over to the\n> sequencer just to match what the am based rebase did.\n\nThere isn’t any more discussion on the patch:\n\nhttps://lore.kernel.org/git/1237399558-27289-3-git-send-email-barra_cuda@katamail.com/\n\n>> [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n>>\n>> I thought about marking it as deprecated but eventually found out why it\n>> was added. And it wasn’t for some (still unknown) dedication or\n>> not-explained *want* to keep the committer date and author date in synch\n>> just-because (as I thought[1]).\n>\n> We should maybe think about deprecating it for \"git rebase\" though as it\n> is a lot less clear that it is sensible there. If you're rebasing a\n> branch then there is a very high likely hood that the upstream committer\n> dates of the commits the branch is being rebased onto will be newer that\n> the author dates of the commits in your branch.\n\nThat makes sense. If there is no use case then it should be deprecated.\n\nI could mark it as such in the next version.\n\nAnyone else have an opinion on this?\n\n>\n> I've left a couple of comments below\n>> diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n>> index 221070de481..c36ae679cfb 100644\n>> --- a/Documentation/git-am.adoc\n>> +++ b/Documentation/git-am.adoc\n>> @@ -156,11 +156,18 @@ Valid for the `--whitespace` option are:\n>> \tSee also linkgit:githooks[5].\n>>\n>> --committer-date-is-author-date::\n>> -\tBy default the command records the date from the e-mail\n>> -\tmessage as the commit author date, and uses the time of\n>> -\tcommit creation as the committer date. This allows the\n>> -\tuser to lie about the committer date by using the same\n>> -\tvalue as the author date.\n>> +\tNOTE: The history walking machinery assumes that commits have\n>> +\tstrictly increasing commit timestamps, with some tolerance for\n>> +\tclock skew (see linkgit:git-rev-list[1]).\n>\n> Is there a particuaar section of the rev-list man page you had in mind\n> here? I had a quick look and I couldn't see anything about clock skew.\n\nNo, I just thought linking to the “history walking command” was apropos.\nI’ll remove it in the next version.\n\n>\n>> You should only use\n>> +\tthis option to lie about the committer date when applying\n>\n> s/lie/override/ ?\n\nI’ll make that change.\n\n>>[snip]\n>> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n>> index 956d3048f5a..336ee90f7e3 100644\n>> --- a/Documentation/git-rebase.adoc\n>> +++ b/Documentation/git-rebase.adoc\n>> @@ -504,9 +504,17 @@ merge backend;;\n>> See also INCOMPATIBLE OPTIONS below.\n>>\n>> --committer-date-is-author-date::\n>> -\tInstead of using the current time as the committer date, use\n>> -\tthe author date of the commit being rebased as the committer\n>> -\tdate. This option implies `--force-rebase`.\n>> +\tNOTE: The history walking machinery assumes that commits have\n>> +\tstrictly increasing commit timestamps, with some tolerance for\n>> +\tclock skew (see linkgit:git-rev-list[1]). You should only use\n>> +\tthis option to lie about the committer date when applying\n>> +\tcommits on top of a base which commit is older (in terms of the\n>\n> The comments above apply here as well. In addition s/applying\n> commits/rebasing commits/ for this command I think.\n\nOkay, thanks.\n\n>\n>> +\tcommit date) than the oldest commit you are applying (in\n>> +\tterms of the author date).\n>\n> We should also warn against using this option when rearranging commits\n> with \"git rebase -i\" as well.\n\nOkay but what does that mean? Should this “note” call out `-i`\nspecifically? And if so why is that?\n\n> Thanks for working on this, it is a very good idea to add a warning to\n> the documentation for this option. I'm going to be off the list for the\n> next 10 days or so, I'll look at any re-roll when I return.\n\nThanks for the review!\n"},{"id":"528400","messageId":"91ddb8c2-ae3a-4b13-a23b-e5cca172ee09@app.fastmail.com","threadId":"62201","inReplyTo":"aae39545-461a-44f0-b01f-bb40b53b1858@app.fastmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2025-10-09T20:47:00Z","receivedAt":"2025-10-09T20:47:23Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Thu, Oct 9, 2025, at 16:31, Kristoffer Haugsbakk wrote:\n>> We should maybe think about deprecating it for \"git rebase\" though as it\n>> is a lot less clear that it is sensible there. If you're rebasing a\n>> branch then there is a very high likely hood that the upstream committer\n>> dates of the commits the branch is being rebased onto will be newer that\n>> the author dates of the commits in your branch.\n>\n> That makes sense. If there is no use case then it should be deprecated.\n>\n> I could mark it as such in the next version.\n>\n> Anyone else have an opinion on this?\n>\n\nBy the way. I thought of adding a stderr warning when using this option\non git-rebase(1). But I don’t think I’ve seen that used in this program\nbefore. If so, why is that? That’s more in your face than just adding it\nto the documentation.\n\nIs it about people parsing stderr, maybe..?\n"},{"id":"528409","messageId":"xmqqo6qfda78.fsf@gitster.g","threadId":"62201","inReplyTo":"3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-09T21:41:47Z","receivedAt":"2025-10-09T21:41:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood writes:\n\n>> You should only use\n>> +\tthis option to lie about the committer date when applying\n>\n> s/lie/override/ ?\n\nIt cannot be \"fixing an earlier mistake by overriding the correct\ndata\". It is deliberately using a data that does not match the\nreality to replace what was recorded, so in this case, \"lie\" would\nbe the proper characterization, I would think.\n\n>> --committer-date-is-author-date::\n>> -\tInstead of using the current time as the committer date, use\n>> -\tthe author date of the commit being rebased as the committer\n>> -\tdate. This option implies `--force-rebase`.\n>> +\tNOTE: The history walking machinery assumes that commits have\n>> +\tstrictly increasing commit timestamps, with some tolerance for\n>> +\tclock skew (see linkgit:git-rev-list[1]). You should only use\n>> +\tthis option to lie about the committer date when applying\n>> +\tcommits on top of a base which commit is older (in terms of the\n>\n> The comments above apply here as well. In addition s/applying \n> commits/rebasing commits/ for this command I think.\n>\n>> +\tcommit date) than the oldest commit you are applying (in\n>> +\tterms of the author date).\n>\n> We should also warn against using this option when rearranging commits \n> with \"git rebase -i\" as well.\n\nTrue.\n\n> Thanks for working on this, it is a very good idea to add a warning to \n> the documentation for this option. I'm going to be off the list for the \n> next 10 days or so, I'll look at any re-roll when I return.\n\n"},{"id":"528422","messageId":"6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com","threadId":"62201","inReplyTo":"xmqqo6qfda78.fsf@gitster.g","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-09T21:57:09Z","receivedAt":"2025-10-09T21:57:31Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 9, 2025, at 23:41, Junio C Hamano wrote:\n> Phillip Wood writes:\n>\n>>> You should only use\n>>> +\tthis option to lie about the committer date when applying\n>>\n>> s/lie/override/ ?\n>\n> It cannot be \"fixing an earlier mistake by overriding the correct\n> data\". It is deliberately using a data that does not match the\n> reality to replace what was recorded, so in this case, \"lie\" would\n> be the proper characterization, I would think.\n\nOkay. I don’t think he was saying “fix” but just the more neutral\n“override”.\n\nI was more confused last year[1] about the use-case here, in turn more\ndismissive; I thought that it was just a vanity thing. I’m all for\ndictating what the author date is since that’s my judgement to make, and\nmoreover such fiddling is naturally tempered by common sense. (Did I\nauthor this between one month ago and now: yes, because I originally\nwrote it one month ago and then amended it three times in this\ntimestamp. Did I author this *three months* ago: No, I hadn’t even\nthought about it at that point. That’s just a lie).\n\nIt’s easy to have a common sense for the authoring date because everyone\nknows of “authoring”. It’s more difficult for people to have common\nsense for the commit date if they don’t know what “committer” is for.\n\nI guess I like the pointed “lie” in this case because uncareful lying\ncan cause technical issues. So you better sharpen your senses and have a\nreal reason for doing it.\n\n🔗 1: https://lore.kernel.org/git/93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com/\n\n>\n>[snip]\n"},{"id":"528424","messageId":"xmqqjz13d9fy.fsf@gitster.g","threadId":"62201","inReplyTo":"91ddb8c2-ae3a-4b13-a23b-e5cca172ee09@app.fastmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-09T21:58:09Z","receivedAt":"2025-10-09T21:58:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" writes:\n\n> On Thu, Oct 9, 2025, at 16:31, Kristoffer Haugsbakk wrote:\n>>> We should maybe think about deprecating it for \"git rebase\" though as it\n>>> is a lot less clear that it is sensible there. If you're rebasing a\n>>> branch then there is a very high likely hood that the upstream committer\n>>> dates of the commits the branch is being rebased onto will be newer that\n>>> the author dates of the commits in your branch.\n>>\n>> That makes sense. If there is no use case then it should be deprecated.\n>>\n>> I could mark it as such in the next version.\n>>\n>> Anyone else have an opinion on this?\n>>\n>\n> By the way. I thought of adding a stderr warning when using this option\n> on git-rebase(1). But I don’t think I’ve seen that used in this program\n> before. If so, why is that? That’s more in your face than just adding it\n> to the documentation.\n>\n> Is it about people parsing stderr, maybe..?\n\nStandard error stream would be buried in other progress things, and\nit won't be seen if you are \"rebase -i\" interactive, in which case\nthe first thing you see is a full-screen editor with list of\ninstructions (where we _could_ add new warning text).\n\n"},{"id":"528432","messageId":"851d8c3a-b812-494f-b981-fa1bc0990428@app.fastmail.com","threadId":"62201","inReplyTo":"xmqqjz13d9fy.fsf@gitster.g","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-09T22:56:42Z","receivedAt":"2025-10-09T22:57:04Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 9, 2025, at 23:58, Junio C Hamano wrote:\n> \"Kristoffer Haugsbakk\" writes:\n>> By the way. I thought of adding a stderr warning when using this option\n>> on git-rebase(1). But I don’t think I’ve seen that used in this program\n>> before. If so, why is that? That’s more in your face than just adding it\n>> to the documentation.\n>>\n>> Is it about people parsing stderr, maybe..?\n>\n> Standard error stream would be buried in other progress things, and\n> it won't be seen if you are \"rebase -i\" interactive, in which case\n> the first thing you see is a full-screen editor with list of\n> instructions\n>\n> (where we _could_ add new warning text).\n\nOoh, that sounds interesting. >:)\n"},{"id":"528564","messageId":"601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org","threadId":"62201","inReplyTo":"d17060d9b72.1759952528.git.code@khaugsbakk.name","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-10-11T09:15:13Z","receivedAt":"2025-10-11T09:15:23Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n> From: Kristoffer Haugsbakk \n> \n> This option has legitimate uses but could create a commit history which\n> violates the assumption that commits are strictly increasing in terms of\n> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n\nI think that the discussion has meanwhile converged insofar that we do\nnot think that the option has a legitimate use case. Rather, it was\nintroduced to solve one particular problem case (that is cited below),\nbut with a solution that was misguided and not well thought through.\n\n> The genesis of this option is 3f01ad66 (am: Add --committer-date-is-\n> author-date option, 2009-01-22). The commit message doesn’t give us an\n> example of a use case, but the thread starter does:[1]\n> \n> I've a big set of patches in a mbox file: there's sufficient info\n> inside for git-am to work.\n> \n> Yet, each time I do import these, my sha1sums are changing because of\n> different commit dates.\n> \n> I'd like to force the commit date to match the info/date from the time\n> I received the email (and therefore always get back the right\n> sha1sums).\n> \n> So the motivation was to treat git-am(1) as an import command that\n> creates the same commit IDs given the same base and committer.\n> \n> [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n\n> diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n> index 221070de481..c36ae679cfb 100644\n> --- a/Documentation/git-am.adoc\n> +++ b/Documentation/git-am.adoc\n> @@ -156,11 +156,18 @@ Valid for the `--whitespace` option are:\n> \tSee also linkgit:githooks[5].\n> \n> --committer-date-is-author-date::\n> -\tBy default the command records the date from the e-mail\n> -\tmessage as the commit author date, and uses the time of\n> -\tcommit creation as the committer date. This allows the\n> -\tuser to lie about the committer date by using the same\n> -\tvalue as the author date.\n> +\tNOTE: The history walking machinery assumes that commits have\n> +\tstrictly increasing commit timestamps, with some tolerance for\n> +\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> +\tthis option to lie about the committer date when applying\n> +\tcommits on top of a base which commit is older (in terms of the\n> +\tcommit date) than the oldest patch you are applying.\n\nIMO, \"NOTE\" is not strong enough, it should be at least \"WARNING\".\n\n> ++\n> +By default the command records the date from the e-mail\n> +message as the commit author date, and uses the time of\n> +commit creation as the committer date. This allows the\n> +user to lie about the committer date by using the same\n> +value as the author date.\n\nI would not mind leaving the description first and the warning in the\nfollow-up paragraph. It would make for a better flow of reading.\n\nPerhaps insert \"Do not use this option.\" as the the first sentence,\neither before the description (my preference) or in the warning.\n\nThank you for picking up this topic.\n\n-- Hannes\n\n"},{"id":"528956","messageId":"52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com","threadId":"62201","inReplyTo":"601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T14:13:11Z","receivedAt":"2025-10-16T14:13:34Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"Good afternoon Hannes\n\nOn Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:\n> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n>> From: Kristoffer Haugsbakk \n>>\n>> This option has legitimate uses but could create a commit history which\n>> violates the assumption that commits are strictly increasing in terms of\n>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n>\n> I think that the discussion has meanwhile converged insofar that we do\n> not think that the option has a legitimate use case. Rather, it was\n> introduced to solve one particular problem case (that is cited below),\n> but with a solution that was misguided and not well thought through.\n\nOkay if this was the cited example:\n\nhttps://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n\nThen we can clarify with two questions:\n\n1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to\n pseudo-import commits (modulo the committer)?\n2. What is a better way to achieve this goal? (assuming (1) is true)\n\n It seemed to me that you might as well use the author date. Unless\n setting max Unix time would be better? Then at least you will never\n manage to apply something on top of something with a newer commit\n timestamp.\n\n† 1: Since this is not what git-am(1) is designed for\n\n>>[snip]\n>> +\tNOTE: The history walking machinery assumes that commits have\n>> +\tstrictly increasing commit timestamps, with some tolerance for\n>> +\tclock skew (see linkgit:git-rev-list[1]). You should only use\n>> +\tthis option to lie about the committer date when applying\n>> +\tcommits on top of a base which commit is older (in terms of the\n>> +\tcommit date) than the oldest patch you are applying.\n>\n> IMO, \"NOTE\" is not strong enough, it should be at least \"WARNING\".\n\nThanks. I’ll do that.\n\n>> ++\n>> +By default the command records the date from the e-mail\n>> +message as the commit author date, and uses the time of\n>> +commit creation as the committer date. This allows the\n>> +user to lie about the committer date by using the same\n>> +value as the author date.\n>\n> I would not mind leaving the description first and the warning in the\n> follow-up paragraph. It would make for a better flow of reading.\n\nOkay. My thought process was that this was important enough to\nfront-load for readers. But regarding flow: the reader can see the\nall-caps keyword and skip the paragraph easily if they want/on repeated\nreads.\n\nBut I’m perfectly fine with leaving it in the second paragraph.\n\nNote: Not relevant here but in case there were more than one paragraph\non this option already: should the WARNING be the final paragraph? Or in\nthe second paragraph? (Like an imporant aside interruption after the\nintroduction.) I think the final one but just clarifying.\n\n> Perhaps insert \"Do not use this option.\" as the the first sentence,\n> either before the description (my preference) or in the warning.\n\nRegarding reading flow, this seems more back-and-forth than this patch.\nBut let’s see.\n\nYou preferred option sounds good to me.\n\nYou say “first sentence” so I guess we’re not making a one-sentence\nparagraph. Like this?\n\n Do not use this option. By default the command records the date from\n the e-mail ...\n\n WARNING: ...\n\nIn that case I think parentheses makes it read better:\n\n (Do not use this option.) By default the command records the date from\n the e-mail ...\n\n WARNING: ...\n\nThanks for the review.\n"},{"id":"528959","messageId":"359272c8-c19d-4480-9902-fb092e2635b1@app.fastmail.com","threadId":"62201","inReplyTo":"52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2025-10-16T15:12:30Z","receivedAt":"2025-10-16T15:12:53Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Thu, Oct 16, 2025, at 16:13, Kristoffer Haugsbakk wrote:\n> Good afternoon Hannes\n>\n> On Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:\n>> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n>>> From: Kristoffer Haugsbakk \n>>>\n>>> This option has legitimate uses but could create a commit history which\n>>> violates the assumption that commits are strictly increasing in terms of\n>>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n>>\n>> I think that the discussion has meanwhile converged insofar that we do\n>> not think that the option has a legitimate use case. Rather, it was\n>> introduced to solve one particular problem case (that is cited below),\n>> but with a solution that was misguided and not well thought through.\n>\n> Okay if this was the cited example:\n>\n> https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n>\n> Then we can clarify with two questions:\n>\n> 1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to\n> pseudo-import commits (modulo the committer)?\n> 2. What is a better way to achieve this goal? (assuming (1) is true)\n>\n> It seemed to me that you might as well use the author date. Unless\n> setting max Unix time would be better? Then at least you will never\n> manage to apply something on top of something with a newer commit\n> timestamp.\n\nTo clarify. My plan for v2 was to deprecate this option for\ngit-rebase(1) but not for git-am(1).\n\n>\n> † 1: Since this is not what git-am(1) is designed for\n>[snip]\n"},{"id":"528962","messageId":"8b7df500-4ddd-4aa4-bc67-b1b345c806e6@kdbg.org","threadId":"62201","inReplyTo":"52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-10-16T15:28:33Z","receivedAt":"2025-10-16T15:28:43Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 16.10.25 um 16:13 schrieb Kristoffer Haugsbakk:\n> On Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:\n>> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n>>> From: Kristoffer Haugsbakk \n>>>\n>>> This option has legitimate uses but could create a commit history which\n>>> violates the assumption that commits are strictly increasing in terms of\n>>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n>>\n>> I think that the discussion has meanwhile converged insofar that we do\n>> not think that the option has a legitimate use case. Rather, it was\n>> introduced to solve one particular problem case (that is cited below),\n>> but with a solution that was misguided and not well thought through.\n> \n> Okay if this was the cited example:\n> \n> https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n> \n> Then we can clarify with two questions:\n> \n> 1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to\n> pseudo-import commits (modulo the committer)?\n\nThe cited example talks about a set of patches and expects them to\ncreate the same object IDs each time they are imported. This expectation\nonly makes sense when the import happens on the same base commit. But\nthen, why in the world would one want to import the same patches\nmultiple times??\n\nA mailbox full of patches is not a suitable storage form for commits.\nThis particular use-case for git-am just does not make sense.\n\n> Note: Not relevant here but in case there were more than one paragraph\n> on this option already: should the WARNING be the final paragraph? Or in\n> the second paragraph? (Like an imporant aside interruption after the\n> introduction.) I think the final one but just clarifying.\n\nIt certainly depends on the case. I think I would begin by putting the\nwarning last and then judge whether a better place is warranted.\n\n>> Perhaps insert \"Do not use this option.\" as the the first sentence,\n>> either before the description (my preference) or in the warning.\n> \n> Regarding reading flow, this seems more back-and-forth than this patch.\n\nFair enough.\n\n> Like this?\n> \n> Do not use this option. By default the command records the date from\n> the e-mail ...\n> \n> WARNING: ...\n> \n> In that case I think parentheses makes it read better:\n> \n> (Do not use this option.) By default the command records the date from\n> the e-mail ...\n> \n> WARNING: ...\nI do not like the latter. If you do not like the former, I wouldn't mind\nnot adding the sentence. The warning should be sufficient.\n\n-- Hannes\n\n"},{"id":"528963","messageId":"6a456b83-f27b-46c2-9b67-4adbac437f4c@app.fastmail.com","threadId":"62201","inReplyTo":"8b7df500-4ddd-4aa4-bc67-b1b345c806e6@kdbg.org","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-16T15:42:09Z","receivedAt":"2025-10-16T15:42:32Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 16, 2025, at 17:28, Johannes Sixt wrote:\n> Am 16.10.25 um 16:13 schrieb Kristoffer Haugsbakk:\n>> On Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:\n>>> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n>>>> From: Kristoffer Haugsbakk \n>>>>\n>>>> This option has legitimate uses but could create a commit history which\n>>>> violates the assumption that commits are strictly increasing in terms of\n>>>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n>>>\n>>> I think that the discussion has meanwhile converged insofar that we do\n>>> not think that the option has a legitimate use case. Rather, it was\n>>> introduced to solve one particular problem case (that is cited below),\n>>> but with a solution that was misguided and not well thought through.\n>>\n>> Okay if this was the cited example:\n>>\n>> https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n>>\n>> Then we can clarify with two questions:\n>>\n>> 1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to\n>> pseudo-import commits (modulo the committer)?\n>\n> The cited example talks about a set of patches and expects them to\n> create the same object IDs each time they are imported. This expectation\n> only makes sense when the import happens on the same base commit. But\n> then, why in the world would one want to import the same patches\n> multiple times??\n\nOkay, a good question. :) The part about that request that I have\nthought about before was using git-am(1) to apply patches to the same\nbase commit and get the same hash. Which would mean fixing both the\ncommitter (to some dummy name) and the committer date. Then someone can\nuse git-am(1) and patches for transport.\n\nBut with this scheme you need to be the same committer. And why would\nthe same committer need to apply the same patches to the same base\nmultiple times? Indeed. :)\n\n>\n> A mailbox full of patches is not a suitable storage form for commits.\n> This particular use-case for git-am just does not make sense.\n\nOkay, then we can scratch that idea (point № 1). In turn the second\npoint becomes irrelevant.\n\nContext for others: Junio’s reply to that request:\n\nhttps://lore.kernel.org/git/7vljt26fp9.fsf@gitster.siamese.dyndns.org/\n\nAside: It seems like we can make a more straightforward change if we all\nagree that this option does not belong to either of these commands. I\nwould not mind that outcome at all.\n\n>>[snip]\n>\n> It certainly depends on the case. I think I would begin by putting the\n> warning last and then judge whether a better place is warranted.\n>\n>>> Perhaps insert \"Do not use this option.\" as the the first sentence,\n>>> either before the description (my preference) or in the warning.\n>>\n>> Regarding reading flow, this seems more back-and-forth than this patch.\n>\n> Fair enough.\n>\n>> Like this?\n>>\n>> Do not use this option. By default the command records the date from\n>> the e-mail ...\n>>\n>> WARNING: ...\n>>\n>> In that case I think parentheses makes it read better:\n>>\n>> (Do not use this option.) By default the command records the date from\n>> the e-mail ...\n>>\n>> WARNING: ...\n> I do not like the latter. If you do not like the former, I wouldn't mind\n> not adding the sentence. The warning should be sufficient.\n\nThanks.\n"},{"id":"528969","messageId":"xmqqbjm695p4.fsf@gitster.g","threadId":"62201","inReplyTo":"8b7df500-4ddd-4aa4-bc67-b1b345c806e6@kdbg.org","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-16T16:23:03Z","receivedAt":"2025-10-16T16:23:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 16.10.25 um 16:13 schrieb Kristoffer Haugsbakk:\n>> On Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:\n>>> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail.com:\n>>>> From: Kristoffer Haugsbakk \n>>>>\n>>>> This option has legitimate uses but could create a commit history which\n>>>> violates the assumption that commits are strictly increasing in terms of\n>>>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n>>>\n>>> I think that the discussion has meanwhile converged insofar that we do\n>>> not think that the option has a legitimate use case. Rather, it was\n>>> introduced to solve one particular problem case (that is cited below),\n>>> but with a solution that was misguided and not well thought through.\n>> \n>> Okay if this was the cited example:\n>> \n>> https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n>> \n>> Then we can clarify with two questions:\n>> \n>> 1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to\n>> pseudo-import commits (modulo the committer)?\n>\n> The cited example talks about a set of patches and expects them to\n> create the same object IDs each time they are imported. This expectation\n> only makes sense when the import happens on the same base commit. But\n> then, why in the world would one want to import the same patches\n> multiple times??\n\nOnly when the person is trying to make sure what they are about to\nsend out _will_ apply cleanly to the intended base, I would guess.\nAnd that person would be using an unstable implementation of \"git\nam\", perhaps who is futzing with it. Otherwise there is no reason\nfor such an expectation. Perhaps back when such a request was made,\nfast-export/fast-import pair was not know to the requestor?\n\n> A mailbox full of patches is not a suitable storage form for commits.\n> This particular use-case for git-am just does not make sense.\n\nI would think so, too.\n\n>> Like this?\n>> \n>> Do not use this option. By default the command records the date from\n>> the e-mail ...\n>> \n>> WARNING: ...\n>> \n>> In that case I think parentheses makes it read better:\n>> \n>> (Do not use this option.) By default the command records the date from\n>> the e-mail ...\n>> \n>> WARNING: ...\n> I do not like the latter. If you do not like the former, I wouldn't mind\n> not adding the sentence. The warning should be sufficient.\n\nBut stepping back a bit, if we truly want to discourage the use of\nit, perhaps we should officially deprecate and schedule it for\nremoval? If we are *not* brave enough to back such a move, then\nperhaps we ourselves are not yet convinced that this should be\ndiscouraged?\n\nMy preference is to stop at describing, in WARNING or NOTES, what\nthe use case that triggered the addition of this option was and\ndeclaring that the use case does not make any sense (your \"who would\napply the same series twice on the same base? just keep the result\non a branch and reuse\" would be fine), but without saying \"Do not\nuse this option\". In other words, the message is \"We'd give a long\nrope that we do not think is very useful, but it is up to you to get\nyourself tangled in it\".\n\nThanks.\n"},{"id":"530997","messageId":"da44a9ce-6e04-43c3-be1a-5db640c20e98@app.fastmail.com","threadId":"62201","inReplyTo":"xmqqbjm695p4.fsf@gitster.g","subject":"Re: [PATCH] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"code@khaugsbakk.name","sentAt":"2025-11-19T16:27:15Z","receivedAt":"2025-11-19T16:27:45Z","isPatch":true,"sender":{"key":"code@khaugsbakk.name","avatar":"https://avatars.githubusercontent.com/u/2229597?v=4"},"body":"On Thu, Oct 16, 2025, at 18:23, Junio C Hamano wrote:\n> Johannes Sixt writes:\n>>[snip]\n>> I do not like the latter. If you do not like the former, I wouldn't mind\n>> not adding the sentence. The warning should be sufficient.\n>\n> But stepping back a bit, if we truly want to discourage the use of\n> it, perhaps we should officially deprecate and schedule it for\n> removal? If we are *not* brave enough to back such a move, then\n> perhaps we ourselves are not yet convinced that this should be\n> discouraged?\n>\n> My preference is to stop at describing, in WARNING or NOTES, what\n> the use case that triggered the addition of this option was and\n> declaring that the use case does not make any sense (your \"who would\n> apply the same series twice on the same base? just keep the result\n> on a branch and reuse\" would be fine), but without saying \"Do not\n> use this option\". In other words, the message is \"We'd give a long\n> rope that we do not think is very useful, but it is up to you to get\n> yourself tangled in it\".\n\nI agree with just warning.\n"},{"id":"531064","messageId":"V2_committer-date-is-author-date.1@msgid.xyz","threadId":"62201","inReplyTo":"d17060d9b72.1759952528.git.code@khaugsbakk.name","subject":"[PATCH v2] doc: warn against --committer-date-is-author-date","fromName":"","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-20T16:26:49Z","receivedAt":"2025-11-20T16:27:05Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"From: Kristoffer Haugsbakk \n\nThis option could create a commit history which violates the assumption\nthat commits have non-decreasing commit timestamps. Warn against that in\nboth git-am(1) and git-rebase(1).\n\nThe genesis of this option is from git-am(1) and was added in\n3f01ad66 (am: Add --committer-date-is-author-date option,\n2009-01-22). The commit message doesn’t give us an example\nof a use case, but the thread starter does:[1]\n\n I've a big set of patches in a mbox file: there's sufficient info\n inside for git-am to work.\n\n Yet, each time I do import these, my sha1sums are changing because of\n different commit dates.\n\n I'd like to force the commit date to match the info/date from the time\n I received the email (and therefore always get back the right\n sha1sums).\n\n[1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n\nSo the motivation was to treat git-am(1) as an import command that\ncreates the same commit IDs.\n\nPutting aside the question of whether you should be using git-am(1) for\nimporting commits, this approach is problematic:\n\n• you still need to apply the commits to the same base if you want the\n same hashes; and\n• you need the same committer.\n\nAnd if you expect the same committer, why is this person applying the\nsame patches multiple times with the goal of making *identical* commits?\n\nThat was all for git-am(1).\n\nIt was added to git-rebase(1) in 570ccad3 (rebase: add options passed to\ngit-am, 2009-03-18)[2] in order to plug options that could not be sent\non to git-am(1). At this point the utility of the option graduated to\nmaking no sense; a use case for `git rebase --committer-date-is-author-\ndate` is still yet to be found.\n\nJust warn against using this option on both commands and remind the user\nto consider whether they really need it.\n\n† 2: See also 7573cec5 (rebase -i: support\n --committer-date-is-author-date, 2020-08-17) for the commit for the\n merge backend\n\nSuggested-by: Johannes Sixt \nSigned-off-by: Kristoffer Haugsbakk \n---\n\nNotes (series):\n Topic name: kh/committer-author-date\n \n Topic summary: \"--committer-date-is-author-date\" can create a history\n with commit timestamps that are not strictly increasing. That doesn't\n play well with the revision walking machinery. Warn against that.\n \n (See https://lore.kernel.org/git/cover.1759873165.git.me@ttaylorr.com/ )\n \n -----\n \n v2:\n \n Add sentence “You should consider if you really need to use this option.”\n in front of “[make sure you] only use this option to ...”.\n \n The problem here is whether to:\n \n 1. Go over the history of why it exists\n 2. Say don’t use it\n 3. Prod them to think about why they are using it\n \n Opt for (3) in the spirit of giving the user the rope they may think\n they need, just with a reminder to consider what they are actually\n trying to achieve.[0]\n \n There was a discussion about deprecating it. But this version still\n just warns.[0]\n \n And:\n \n • Commit message: Drop “legitimate uses” after reviewer feedback and\n discussion. The message goes into why the reported use case does not make\n enough sense\n • Use `WARNING` as a callout instead of `NOTE`[1]\n • Put the warning paragraph second/last[2]\n • Commit message: Use “override” instead of “lie”.[3] Either works but\n “override” is more neutral[4] and not less forthright.\n • Drop “clock skew” and git-rev-list(1) mention[5]\n • Commit message: Tweak “The genesis” paragraph: “is from git-am(1)” since\n most of the explanation goes over the git-am(1) option\n • Use “non-decreasing commit timestamps”. I guess “strictly increasing”\n means that the commit timestamps need to be greater for each. But a commit\n B that follows A can have the same timestamp, that’s ok.\n • s/applying commits/rebasing commits/ in git-rebase(1)[6]\n \n 🔗 0: https://lore.kernel.org/git/xmqqbjm695p4.fsf@gitster.g/#t\n 🔗 1: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n 🔗 2: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n 🔗 3: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n 🔗 4: https://lore.kernel.org/git/6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com/\n 🔗 5: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n 🔗 6: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n \n v1:\n \n I thought about marking it as deprecated but eventually found out why it\n was added. And it wasn’t for some (still unknown) dedication or\n not-explained *want* to keep the committer date and author date in synch\n just-because (as I thought[1]).\n \n Hannes asked[2] why it is a porcelain option? (You can after all script\n the same behavior with a little effort.) Personally I think the Git\n porcelain is not shy about providing facilities for crafting made-up\n histories to its users. And I personally think that’s a good thing.\n \n This does seem to indicate that this option doesn’t make much sense for\n git-rebase(1) though, no? Given that it will `--force-rebase`, i.e. will\n force new commit IDs.\n \n 🔗 1: https://lore.kernel.org/git/93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com/\n 🔗 2: https://lore.kernel.org/git/6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org/\n\n Documentation/git-am.adoc | 7 +++++++\n Documentation/git-rebase.adoc | 7 +++++++\n 2 files changed, 14 insertions(+)\n\ndiff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\nindex 221070de481..264d21a7de7 100644\n--- a/Documentation/git-am.adoc\n+++ b/Documentation/git-am.adoc\n@@ -161,6 +161,13 @@ Valid for the `--whitespace` option are:\n \tcommit creation as the committer date. This allows the\n \tuser to lie about the committer date by using the same\n \tvalue as the author date.\n++\n+WARNING: The history walking machinery assumes that commits have\n+non-decreasing commit timestamps. You should consider if you really need\n+to use this option. Then you should only use this option to override the\n+committer date when applying commits on top of a base which commit is\n+older (in terms of the commit date) than the oldest patch you are\n+applying.\n \n --ignore-date::\n \tBy default the command records the date from the e-mail\ndiff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\nindex 956d3048f5a..0f808c82b28 100644\n--- a/Documentation/git-rebase.adoc\n+++ b/Documentation/git-rebase.adoc\n@@ -507,6 +507,13 @@ See also INCOMPATIBLE OPTIONS below.\n \tInstead of using the current time as the committer date, use\n \tthe author date of the commit being rebased as the committer\n \tdate. This option implies `--force-rebase`.\n++\n+WARNING: The history walking machinery assumes that commits have\n+non-decreasing commit timestamps. You should consider if you really need\n+to use this option. Then you should only use this option to override the\n+committer date when rebasing commits on top of a base which commit is\n+older (in terms of the commit date) than the oldest commit you are\n+applying (in terms of the author date).\n \n --ignore-date::\n --reset-author-date::\n\nInterdiff against v1:\n diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n index c36ae679cfb..264d21a7de7 100644\n --- a/Documentation/git-am.adoc\n +++ b/Documentation/git-am.adoc\n @@ -156,18 +156,18 @@ Valid for the `--whitespace` option are:\n \tSee also linkgit:githooks[5].\n \n --committer-date-is-author-date::\n -\tNOTE: The history walking machinery assumes that commits have\n -\tstrictly increasing commit timestamps, with some tolerance for\n -\tclock skew (see linkgit:git-rev-list[1]). You should only use\n -\tthis option to lie about the committer date when applying\n -\tcommits on top of a base which commit is older (in terms of the\n -\tcommit date) than the oldest patch you are applying.\n +\tBy default the command records the date from the e-mail\n +\tmessage as the commit author date, and uses the time of\n +\tcommit creation as the committer date. This allows the\n +\tuser to lie about the committer date by using the same\n +\tvalue as the author date.\n +\n -By default the command records the date from the e-mail\n -message as the commit author date, and uses the time of\n -commit creation as the committer date. This allows the\n -user to lie about the committer date by using the same\n -value as the author date.\n +WARNING: The history walking machinery assumes that commits have\n +non-decreasing commit timestamps. You should consider if you really need\n +to use this option. Then you should only use this option to override the\n +committer date when applying commits on top of a base which commit is\n +older (in terms of the commit date) than the oldest patch you are\n +applying.\n \n --ignore-date::\n \tBy default the command records the date from the e-mail\n diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n index 336ee90f7e3..0f808c82b28 100644\n --- a/Documentation/git-rebase.adoc\n +++ b/Documentation/git-rebase.adoc\n @@ -504,17 +504,16 @@ merge backend;;\n See also INCOMPATIBLE OPTIONS below.\n \n --committer-date-is-author-date::\n -\tNOTE: The history walking machinery assumes that commits have\n -\tstrictly increasing commit timestamps, with some tolerance for\n -\tclock skew (see linkgit:git-rev-list[1]). You should only use\n -\tthis option to lie about the committer date when applying\n -\tcommits on top of a base which commit is older (in terms of the\n -\tcommit date) than the oldest commit you are applying (in\n -\tterms of the author date).\n +\tInstead of using the current time as the committer date, use\n +\tthe author date of the commit being rebased as the committer\n +\tdate. This option implies `--force-rebase`.\n +\n -Instead of using the current time as the committer date, use\n -the author date of the commit being rebased as the committer\n -date. This option implies `--force-rebase`.\n +WARNING: The history walking machinery assumes that commits have\n +non-decreasing commit timestamps. You should consider if you really need\n +to use this option. Then you should only use this option to override the\n +committer date when rebasing commits on top of a base which commit is\n +older (in terms of the commit date) than the oldest commit you are\n +applying (in terms of the author date).\n \n --ignore-date::\n --reset-author-date::\n\nRange-diff against v1:\n1: d17060d9b72 ! 1: 203a9b9db2c doc: warn against --committer-date-is-author-date\n @@ Metadata\n ## Commit message ##\n doc: warn against --committer-date-is-author-date\n \n - This option has legitimate uses but could create a commit history which\n - violates the assumption that commits are strictly increasing in terms of\n - commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n + This option could create a commit history which violates the assumption\n + that commits have non-decreasing commit timestamps. Warn against that in\n + both git-am(1) and git-rebase(1).\n \n - ❦\n -\n - The genesis of this option is 3f01ad66 (am: Add --committer-date-is-\n - author-date option, 2009-01-22). The commit message doesn’t give us an\n - example of a use case, but the thread starter does:[1]\n + The genesis of this option is from git-am(1) and was added in\n + 3f01ad66 (am: Add --committer-date-is-author-date option,\n + 2009-01-22). The commit message doesn’t give us an example\n + of a use case, but the thread starter does:[1]\n \n I've a big set of patches in a mbox file: there's sufficient info\n inside for git-am to work.\n @@ Commit message\n I received the email (and therefore always get back the right\n sha1sums).\n \n + [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n +\n So the motivation was to treat git-am(1) as an import command that\n - creates the same commit IDs given the same base and committer.\n + creates the same commit IDs.\n \n - [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n + Putting aside the question of whether you should be using git-am(1) for\n + importing commits, this approach is problematic:\n +\n + • you still need to apply the commits to the same base if you want the\n + same hashes; and\n + • you need the same committer.\n +\n + And if you expect the same committer, why is this person applying the\n + same patches multiple times with the goal of making *identical* commits?\n +\n + That was all for git-am(1).\n +\n + It was added to git-rebase(1) in 570ccad3 (rebase: add options passed to\n + git-am, 2009-03-18)[2] in order to plug options that could not be sent\n + on to git-am(1). At this point the utility of the option graduated to\n + making no sense; a use case for `git rebase --committer-date-is-author-\n + date` is still yet to be found.\n +\n + Just warn against using this option on both commands and remind the user\n + to consider whether they really need it.\n +\n + † 2: See also 7573cec5 (rebase -i: support\n + --committer-date-is-author-date, 2020-08-17) for the commit for the\n + merge backend\n \n Suggested-by: Johannes Sixt \n Signed-off-by: Kristoffer Haugsbakk \n @@ Notes (series)\n \n v2:\n \n - • Deprecate in addition to warning\n + Add sentence “You should consider if you really need to use this option.”\n + in front of “[make sure you] only use this option to ...”.\n +\n + The problem here is whether to:\n +\n + 1. Go over the history of why it exists\n + 2. Say don’t use it\n + 3. Prod them to think about why they are using it\n +\n + Opt for (3) in the spirit of giving the user the rope they may think\n + they need, just with a reminder to consider what they are actually\n + trying to achieve.[0]\n +\n + There was a discussion about deprecating it. But this version still\n + just warns.[0]\n +\n + And:\n +\n + • Commit message: Drop “legitimate uses” after reviewer feedback and\n + discussion. The message goes into why the reported use case does not make\n + enough sense\n • Use `WARNING` as a callout instead of `NOTE`[1]\n • Put the warning paragraph second/last[2]\n - • Use “override” instead of “lie”.[3] Either works but “override” is\n - more neutral[4] and not less forthright.\n + • Commit message: Use “override” instead of “lie”.[3] Either works but\n + “override” is more neutral[4] and not less forthright.\n • Drop “clock skew” and git-rev-list(1) mention[5]\n -\n + • Commit message: Tweak “The genesis” paragraph: “is from git-am(1)” since\n + most of the explanation goes over the git-am(1) option\n + • Use “non-decreasing commit timestamps”. I guess “strictly increasing”\n + means that the commit timestamps need to be greater for each. But a commit\n + B that follows A can have the same timestamp, that’s ok.\n + • s/applying commits/rebasing commits/ in git-rebase(1)[6]\n +\n + 🔗 0: https://lore.kernel.org/git/xmqqbjm695p4.fsf@gitster.g/#t\n 🔗 1: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n 🔗 2: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n 🔗 3: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n 🔗 4: https://lore.kernel.org/git/6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com/\n 🔗 5: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n + 🔗 6: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n \n v1:\n \n @@ Notes (series)\n \n ## Documentation/git-am.adoc ##\n @@ Documentation/git-am.adoc: Valid for the `--whitespace` option are:\n - \tSee also linkgit:githooks[5].\n - \n - --committer-date-is-author-date::\n --\tBy default the command records the date from the e-mail\n --\tmessage as the commit author date, and uses the time of\n --\tcommit creation as the committer date. This allows the\n --\tuser to lie about the committer date by using the same\n --\tvalue as the author date.\n -+\tNOTE: The history walking machinery assumes that commits have\n -+\tstrictly increasing commit timestamps, with some tolerance for\n -+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n -+\tthis option to lie about the committer date when applying\n -+\tcommits on top of a base which commit is older (in terms of the\n -+\tcommit date) than the oldest patch you are applying.\n + \tcommit creation as the committer date. This allows the\n + \tuser to lie about the committer date by using the same\n + \tvalue as the author date.\n ++\n -+By default the command records the date from the e-mail\n -+message as the commit author date, and uses the time of\n -+commit creation as the committer date. This allows the\n -+user to lie about the committer date by using the same\n -+value as the author date.\n ++WARNING: The history walking machinery assumes that commits have\n ++non-decreasing commit timestamps. You should consider if you really need\n ++to use this option. Then you should only use this option to override the\n ++committer date when applying commits on top of a base which commit is\n ++older (in terms of the commit date) than the oldest patch you are\n ++applying.\n \n --ignore-date::\n \tBy default the command records the date from the e-mail\n \n ## Documentation/git-rebase.adoc ##\n -@@ Documentation/git-rebase.adoc: merge backend;;\n - See also INCOMPATIBLE OPTIONS below.\n - \n - --committer-date-is-author-date::\n --\tInstead of using the current time as the committer date, use\n --\tthe author date of the commit being rebased as the committer\n --\tdate. This option implies `--force-rebase`.\n -+\tNOTE: The history walking machinery assumes that commits have\n -+\tstrictly increasing commit timestamps, with some tolerance for\n -+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n -+\tthis option to lie about the committer date when applying\n -+\tcommits on top of a base which commit is older (in terms of the\n -+\tcommit date) than the oldest commit you are applying (in\n -+\tterms of the author date).\n +@@ Documentation/git-rebase.adoc: See also INCOMPATIBLE OPTIONS below.\n + \tInstead of using the current time as the committer date, use\n + \tthe author date of the commit being rebased as the committer\n + \tdate. This option implies `--force-rebase`.\n ++\n -+Instead of using the current time as the committer date, use\n -+the author date of the commit being rebased as the committer\n -+date. This option implies `--force-rebase`.\n ++WARNING: The history walking machinery assumes that commits have\n ++non-decreasing commit timestamps. You should consider if you really need\n ++to use this option. Then you should only use this option to override the\n ++committer date when rebasing commits on top of a base which commit is\n ++older (in terms of the commit date) than the oldest commit you are\n ++applying (in terms of the author date).\n \n --ignore-date::\n --reset-author-date::\n\nbase-commit: c44beea485f0f2feaf460e2ac87fdd5608d63cf0\n-- \n2.52.0.10.g08704017180\n\n"},{"id":"531068","messageId":"f3c586b0-e7a8-4cf1-96ac-ac8bd0dfcff4@kdbg.org","threadId":"62201","inReplyTo":"V2_committer-date-is-author-date.1@msgid.xyz","subject":"Re: [PATCH v2] doc: warn against --committer-date-is-author-date","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-11-20T17:19:28Z","receivedAt":"2025-11-20T17:19:47Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Thank you, this round looks good to me!\n\n-- Hannes\n\n"},{"id":"531307","messageId":"061c627f-46a4-4da7-af5e-17fda552e29a@gmail.com","threadId":"62201","inReplyTo":"V2_committer-date-is-author-date.1@msgid.xyz","subject":"Re: [PATCH v2] doc: warn against --committer-date-is-author-date","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-11-26T16:02:35Z","receivedAt":"2025-11-26T16:02:44Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Kristoffer\n\nThis looks good, I appreciate the detail in the commit message. Sorry \nI've only just got round to looking at it.\n\nThanks\n\nPhillip\n\nOn 20/11/2025 16:26, kristofferhaugsbakk@fastmail.com wrote:\n> From: Kristoffer Haugsbakk \n> \n> This option could create a commit history which violates the assumption\n> that commits have non-decreasing commit timestamps. Warn against that in\n> both git-am(1) and git-rebase(1).\n> \n> The genesis of this option is from git-am(1) and was added in\n> 3f01ad66 (am: Add --committer-date-is-author-date option,\n> 2009-01-22). The commit message doesn’t give us an example\n> of a use case, but the thread starter does:[1]\n> \n> I've a big set of patches in a mbox file: there's sufficient info\n> inside for git-am to work.\n> \n> Yet, each time I do import these, my sha1sums are changing because of\n> different commit dates.\n> \n> I'd like to force the commit date to match the info/date from the time\n> I received the email (and therefore always get back the right\n> sha1sums).\n> \n> [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n> \n> So the motivation was to treat git-am(1) as an import command that\n> creates the same commit IDs.\n> \n> Putting aside the question of whether you should be using git-am(1) for\n> importing commits, this approach is problematic:\n> \n> • you still need to apply the commits to the same base if you want the\n> same hashes; and\n> • you need the same committer.\n> \n> And if you expect the same committer, why is this person applying the\n> same patches multiple times with the goal of making *identical* commits?\n> \n> That was all for git-am(1).\n> \n> It was added to git-rebase(1) in 570ccad3 (rebase: add options passed to\n> git-am, 2009-03-18)[2] in order to plug options that could not be sent\n> on to git-am(1). At this point the utility of the option graduated to\n> making no sense; a use case for `git rebase --committer-date-is-author-\n> date` is still yet to be found.\n> \n> Just warn against using this option on both commands and remind the user\n> to consider whether they really need it.\n> \n> † 2: See also 7573cec5 (rebase -i: support\n> --committer-date-is-author-date, 2020-08-17) for the commit for the\n> merge backend\n> \n> Suggested-by: Johannes Sixt \n> Signed-off-by: Kristoffer Haugsbakk \n> ---\n> \n> Notes (series):\n> Topic name: kh/committer-author-date\n> \n> Topic summary: \"--committer-date-is-author-date\" can create a history\n> with commit timestamps that are not strictly increasing. That doesn't\n> play well with the revision walking machinery. Warn against that.\n> \n> (See https://lore.kernel.org/git/cover.1759873165.git.me@ttaylorr.com/ )\n> \n> -----\n> \n> v2:\n> \n> Add sentence “You should consider if you really need to use this option.”\n> in front of “[make sure you] only use this option to ...”.\n> \n> The problem here is whether to:\n> \n> 1. Go over the history of why it exists\n> 2. Say don’t use it\n> 3. Prod them to think about why they are using it\n> \n> Opt for (3) in the spirit of giving the user the rope they may think\n> they need, just with a reminder to consider what they are actually\n> trying to achieve.[0]\n> \n> There was a discussion about deprecating it. But this version still\n> just warns.[0]\n> \n> And:\n> \n> • Commit message: Drop “legitimate uses” after reviewer feedback and\n> discussion. The message goes into why the reported use case does not make\n> enough sense\n> • Use `WARNING` as a callout instead of `NOTE`[1]\n> • Put the warning paragraph second/last[2]\n> • Commit message: Use “override” instead of “lie”.[3] Either works but\n> “override” is more neutral[4] and not less forthright.\n> • Drop “clock skew” and git-rev-list(1) mention[5]\n> • Commit message: Tweak “The genesis” paragraph: “is from git-am(1)” since\n> most of the explanation goes over the git-am(1) option\n> • Use “non-decreasing commit timestamps”. I guess “strictly increasing”\n> means that the commit timestamps need to be greater for each. But a commit\n> B that follows A can have the same timestamp, that’s ok.\n> • s/applying commits/rebasing commits/ in git-rebase(1)[6]\n> \n> 🔗 0: https://lore.kernel.org/git/xmqqbjm695p4.fsf@gitster.g/#t\n> 🔗 1: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n> 🔗 2: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n> 🔗 3: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> 🔗 4: https://lore.kernel.org/git/6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com/\n> 🔗 5: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> 🔗 6: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> \n> v1:\n> \n> I thought about marking it as deprecated but eventually found out why it\n> was added. And it wasn’t for some (still unknown) dedication or\n> not-explained *want* to keep the committer date and author date in synch\n> just-because (as I thought[1]).\n> \n> Hannes asked[2] why it is a porcelain option? (You can after all script\n> the same behavior with a little effort.) Personally I think the Git\n> porcelain is not shy about providing facilities for crafting made-up\n> histories to its users. And I personally think that’s a good thing.\n> \n> This does seem to indicate that this option doesn’t make much sense for\n> git-rebase(1) though, no? Given that it will `--force-rebase`, i.e. will\n> force new commit IDs.\n> \n> 🔗 1: https://lore.kernel.org/git/93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com/\n> 🔗 2: https://lore.kernel.org/git/6af09726-e3bf-4903-87ae-9524ad334678@kdbg.org/\n> \n> Documentation/git-am.adoc | 7 +++++++\n> Documentation/git-rebase.adoc | 7 +++++++\n> 2 files changed, 14 insertions(+)\n> \n> diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n> index 221070de481..264d21a7de7 100644\n> --- a/Documentation/git-am.adoc\n> +++ b/Documentation/git-am.adoc\n> @@ -161,6 +161,13 @@ Valid for the `--whitespace` option are:\n> \tcommit creation as the committer date. This allows the\n> \tuser to lie about the committer date by using the same\n> \tvalue as the author date.\n> ++\n> +WARNING: The history walking machinery assumes that commits have\n> +non-decreasing commit timestamps. You should consider if you really need\n> +to use this option. Then you should only use this option to override the\n> +committer date when applying commits on top of a base which commit is\n> +older (in terms of the commit date) than the oldest patch you are\n> +applying.\n> \n> --ignore-date::\n> \tBy default the command records the date from the e-mail\n> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n> index 956d3048f5a..0f808c82b28 100644\n> --- a/Documentation/git-rebase.adoc\n> +++ b/Documentation/git-rebase.adoc\n> @@ -507,6 +507,13 @@ See also INCOMPATIBLE OPTIONS below.\n> \tInstead of using the current time as the committer date, use\n> \tthe author date of the commit being rebased as the committer\n> \tdate. This option implies `--force-rebase`.\n> ++\n> +WARNING: The history walking machinery assumes that commits have\n> +non-decreasing commit timestamps. You should consider if you really need\n> +to use this option. Then you should only use this option to override the\n> +committer date when rebasing commits on top of a base which commit is\n> +older (in terms of the commit date) than the oldest commit you are\n> +applying (in terms of the author date).\n> \n> --ignore-date::\n> --reset-author-date::\n> \n> Interdiff against v1:\n> diff --git a/Documentation/git-am.adoc b/Documentation/git-am.adoc\n> index c36ae679cfb..264d21a7de7 100644\n> --- a/Documentation/git-am.adoc\n> +++ b/Documentation/git-am.adoc\n> @@ -156,18 +156,18 @@ Valid for the `--whitespace` option are:\n> \tSee also linkgit:githooks[5].\n> \n> --committer-date-is-author-date::\n> -\tNOTE: The history walking machinery assumes that commits have\n> -\tstrictly increasing commit timestamps, with some tolerance for\n> -\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> -\tthis option to lie about the committer date when applying\n> -\tcommits on top of a base which commit is older (in terms of the\n> -\tcommit date) than the oldest patch you are applying.\n> +\tBy default the command records the date from the e-mail\n> +\tmessage as the commit author date, and uses the time of\n> +\tcommit creation as the committer date. This allows the\n> +\tuser to lie about the committer date by using the same\n> +\tvalue as the author date.\n> +\n> -By default the command records the date from the e-mail\n> -message as the commit author date, and uses the time of\n> -commit creation as the committer date. This allows the\n> -user to lie about the committer date by using the same\n> -value as the author date.\n> +WARNING: The history walking machinery assumes that commits have\n> +non-decreasing commit timestamps. You should consider if you really need\n> +to use this option. Then you should only use this option to override the\n> +committer date when applying commits on top of a base which commit is\n> +older (in terms of the commit date) than the oldest patch you are\n> +applying.\n> \n> --ignore-date::\n> \tBy default the command records the date from the e-mail\n> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n> index 336ee90f7e3..0f808c82b28 100644\n> --- a/Documentation/git-rebase.adoc\n> +++ b/Documentation/git-rebase.adoc\n> @@ -504,17 +504,16 @@ merge backend;;\n> See also INCOMPATIBLE OPTIONS below.\n> \n> --committer-date-is-author-date::\n> -\tNOTE: The history walking machinery assumes that commits have\n> -\tstrictly increasing commit timestamps, with some tolerance for\n> -\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> -\tthis option to lie about the committer date when applying\n> -\tcommits on top of a base which commit is older (in terms of the\n> -\tcommit date) than the oldest commit you are applying (in\n> -\tterms of the author date).\n> +\tInstead of using the current time as the committer date, use\n> +\tthe author date of the commit being rebased as the committer\n> +\tdate. This option implies `--force-rebase`.\n> +\n> -Instead of using the current time as the committer date, use\n> -the author date of the commit being rebased as the committer\n> -date. This option implies `--force-rebase`.\n> +WARNING: The history walking machinery assumes that commits have\n> +non-decreasing commit timestamps. You should consider if you really need\n> +to use this option. Then you should only use this option to override the\n> +committer date when rebasing commits on top of a base which commit is\n> +older (in terms of the commit date) than the oldest commit you are\n> +applying (in terms of the author date).\n> \n> --ignore-date::\n> --reset-author-date::\n> \n> Range-diff against v1:\n> 1: d17060d9b72 ! 1: 203a9b9db2c doc: warn against --committer-date-is-author-date\n> @@ Metadata\n> ## Commit message ##\n> doc: warn against --committer-date-is-author-date\n> \n> - This option has legitimate uses but could create a commit history which\n> - violates the assumption that commits are strictly increasing in terms of\n> - commit timestamps. Warn against that in both git-am(1) and git-rebase(1).\n> + This option could create a commit history which violates the assumption\n> + that commits have non-decreasing commit timestamps. Warn against that in\n> + both git-am(1) and git-rebase(1).\n> \n> - ❦\n> -\n> - The genesis of this option is 3f01ad66 (am: Add --committer-date-is-\n> - author-date option, 2009-01-22). The commit message doesn’t give us an\n> - example of a use case, but the thread starter does:[1]\n> + The genesis of this option is from git-am(1) and was added in\n> + 3f01ad66 (am: Add --committer-date-is-author-date option,\n> + 2009-01-22). The commit message doesn’t give us an example\n> + of a use case, but the thread starter does:[1]\n> \n> I've a big set of patches in a mbox file: there's sufficient info\n> inside for git-am to work.\n> @@ Commit message\n> I received the email (and therefore always get back the right\n> sha1sums).\n> \n> + [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n> +\n> So the motivation was to treat git-am(1) as an import command that\n> - creates the same commit IDs given the same base and committer.\n> + creates the same commit IDs.\n> \n> - [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/\n> + Putting aside the question of whether you should be using git-am(1) for\n> + importing commits, this approach is problematic:\n> +\n> + • you still need to apply the commits to the same base if you want the\n> + same hashes; and\n> + • you need the same committer.\n> +\n> + And if you expect the same committer, why is this person applying the\n> + same patches multiple times with the goal of making *identical* commits?\n> +\n> + That was all for git-am(1).\n> +\n> + It was added to git-rebase(1) in 570ccad3 (rebase: add options passed to\n> + git-am, 2009-03-18)[2] in order to plug options that could not be sent\n> + on to git-am(1). At this point the utility of the option graduated to\n> + making no sense; a use case for `git rebase --committer-date-is-author-\n> + date` is still yet to be found.\n> +\n> + Just warn against using this option on both commands and remind the user\n> + to consider whether they really need it.\n> +\n> + † 2: See also 7573cec5 (rebase -i: support\n> + --committer-date-is-author-date, 2020-08-17) for the commit for the\n> + merge backend\n> \n> Suggested-by: Johannes Sixt \n> Signed-off-by: Kristoffer Haugsbakk \n> @@ Notes (series)\n> \n> v2:\n> \n> - • Deprecate in addition to warning\n> + Add sentence “You should consider if you really need to use this option.”\n> + in front of “[make sure you] only use this option to ...”.\n> +\n> + The problem here is whether to:\n> +\n> + 1. Go over the history of why it exists\n> + 2. Say don’t use it\n> + 3. Prod them to think about why they are using it\n> +\n> + Opt for (3) in the spirit of giving the user the rope they may think\n> + they need, just with a reminder to consider what they are actually\n> + trying to achieve.[0]\n> +\n> + There was a discussion about deprecating it. But this version still\n> + just warns.[0]\n> +\n> + And:\n> +\n> + • Commit message: Drop “legitimate uses” after reviewer feedback and\n> + discussion. The message goes into why the reported use case does not make\n> + enough sense\n> • Use `WARNING` as a callout instead of `NOTE`[1]\n> • Put the warning paragraph second/last[2]\n> - • Use “override” instead of “lie”.[3] Either works but “override” is\n> - more neutral[4] and not less forthright.\n> + • Commit message: Use “override” instead of “lie”.[3] Either works but\n> + “override” is more neutral[4] and not less forthright.\n> • Drop “clock skew” and git-rev-list(1) mention[5]\n> -\n> + • Commit message: Tweak “The genesis” paragraph: “is from git-am(1)” since\n> + most of the explanation goes over the git-am(1) option\n> + • Use “non-decreasing commit timestamps”. I guess “strictly increasing”\n> + means that the commit timestamps need to be greater for each. But a commit\n> + B that follows A can have the same timestamp, that’s ok.\n> + • s/applying commits/rebasing commits/ in git-rebase(1)[6]\n> +\n> + 🔗 0: https://lore.kernel.org/git/xmqqbjm695p4.fsf@gitster.g/#t\n> 🔗 1: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n> 🔗 2: https://lore.kernel.org/git/601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org/\n> 🔗 3: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> 🔗 4: https://lore.kernel.org/git/6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com/\n> 🔗 5: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> + 🔗 6: https://lore.kernel.org/git/3a8dfd13-982d-4c83-b675-1e9a63bb6ab0@gmail.com/\n> \n> v1:\n> \n> @@ Notes (series)\n> \n> ## Documentation/git-am.adoc ##\n> @@ Documentation/git-am.adoc: Valid for the `--whitespace` option are:\n> - \tSee also linkgit:githooks[5].\n> -\n> - --committer-date-is-author-date::\n> --\tBy default the command records the date from the e-mail\n> --\tmessage as the commit author date, and uses the time of\n> --\tcommit creation as the committer date. This allows the\n> --\tuser to lie about the committer date by using the same\n> --\tvalue as the author date.\n> -+\tNOTE: The history walking machinery assumes that commits have\n> -+\tstrictly increasing commit timestamps, with some tolerance for\n> -+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> -+\tthis option to lie about the committer date when applying\n> -+\tcommits on top of a base which commit is older (in terms of the\n> -+\tcommit date) than the oldest patch you are applying.\n> + \tcommit creation as the committer date. This allows the\n> + \tuser to lie about the committer date by using the same\n> + \tvalue as the author date.\n> ++\n> -+By default the command records the date from the e-mail\n> -+message as the commit author date, and uses the time of\n> -+commit creation as the committer date. This allows the\n> -+user to lie about the committer date by using the same\n> -+value as the author date.\n> ++WARNING: The history walking machinery assumes that commits have\n> ++non-decreasing commit timestamps. You should consider if you really need\n> ++to use this option. Then you should only use this option to override the\n> ++committer date when applying commits on top of a base which commit is\n> ++older (in terms of the commit date) than the oldest patch you are\n> ++applying.\n> \n> --ignore-date::\n> \tBy default the command records the date from the e-mail\n> \n> ## Documentation/git-rebase.adoc ##\n> -@@ Documentation/git-rebase.adoc: merge backend;;\n> - See also INCOMPATIBLE OPTIONS below.\n> -\n> - --committer-date-is-author-date::\n> --\tInstead of using the current time as the committer date, use\n> --\tthe author date of the commit being rebased as the committer\n> --\tdate. This option implies `--force-rebase`.\n> -+\tNOTE: The history walking machinery assumes that commits have\n> -+\tstrictly increasing commit timestamps, with some tolerance for\n> -+\tclock skew (see linkgit:git-rev-list[1]). You should only use\n> -+\tthis option to lie about the committer date when applying\n> -+\tcommits on top of a base which commit is older (in terms of the\n> -+\tcommit date) than the oldest commit you are applying (in\n> -+\tterms of the author date).\n> +@@ Documentation/git-rebase.adoc: See also INCOMPATIBLE OPTIONS below.\n> + \tInstead of using the current time as the committer date, use\n> + \tthe author date of the commit being rebased as the committer\n> + \tdate. This option implies `--force-rebase`.\n> ++\n> -+Instead of using the current time as the committer date, use\n> -+the author date of the commit being rebased as the committer\n> -+date. This option implies `--force-rebase`.\n> ++WARNING: The history walking machinery assumes that commits have\n> ++non-decreasing commit timestamps. You should consider if you really need\n> ++to use this option. Then you should only use this option to override the\n> ++committer date when rebasing commits on top of a base which commit is\n> ++older (in terms of the commit date) than the oldest commit you are\n> ++applying (in terms of the author date).\n> \n> --ignore-date::\n> --reset-author-date::\n> \n> base-commit: c44beea485f0f2feaf460e2ac87fdd5608d63cf0\n\n"},{"id":"531368","messageId":"5dfbd78a-6ee9-4949-91b6-905cdbad833f@app.fastmail.com","threadId":"62201","inReplyTo":"061c627f-46a4-4da7-af5e-17fda552e29a@gmail.com","subject":"Re: [PATCH v2] doc: warn against --committer-date-is-author-date","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-27T06:30:03Z","receivedAt":"2025-11-27T06:30:34Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Wed, Nov 26, 2025, at 17:02, Phillip Wood wrote:\n> Hi Kristoffer\n>\n> This looks good, I appreciate the detail in the commit message. Sorry\n> I've only just got round to looking at it.\n\nThanks Johannes, Phillip.\n"}]}