{"thread":{"id":"57586","subject":"using oldest date when squashing commits","startedAt":"2022-03-19T12:48:56Z","lastAt":"2023-10-27T23:24:59Z","messageCount":15,"participants":["Oswald Buddenhagen","Johannes Sixt","Phillip Wood","Junio C Hamano","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"451672","messageId":"YjXRM5HiRizZ035p@ugly","threadId":"57586","inReplyTo":null,"subject":"using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2022-03-19T12:48:51Z","receivedAt":"2022-03-19T12:48:56Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"moin,\n\nduring interactive rebasing, i sometimes find it necessary to move a \nhunk from one commit to a later one in the branch. now, if that hunk \ncannot be re-ordered with the later commit due to conflicting with it, \nit becomes necessary to squash the later commit onto a temporary commit \ncreated from the extracted hunk, not the other way around (or using a \nstash). unfortunately, this causes the author date of the later commit \nto be reset, which can rather seriously falsify the date if the branch \nis long-lived.\n\ni know how to manually work around that, but that's not exactly user \nfriendly.\n\nmy first thought was to create an --oldest-date option (essentially \ncomplementary to --ignore-date).\n\nbut i wonder whether it even needs to be an option? why would anyone not \nwant that behavior, unless they are explicitly resetting the date \nanyway?\n\nthanks\n"},{"id":"451682","messageId":"9fae5292-d58f-95da-245b-6e205383cb50@kdbg.org","threadId":"57586","inReplyTo":"YjXRM5HiRizZ035p@ugly","subject":"Re: using oldest date when squashing commits","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2022-03-20T08:05:45Z","receivedAt":"2022-03-20T08:05:51Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:\n> during interactive rebasing, i sometimes find it necessary to move a\n> hunk from one commit to a later one in the branch. now, if that hunk\n> cannot be re-ordered with the later commit due to conflicting with it,\n> it becomes necessary to squash the later commit onto a temporary commit\n> created from the extracted hunk, not the other way around (or using a\n> stash). unfortunately, this causes the author date of the later commit\n> to be reset, which can rather seriously falsify the date if the branch\n> is long-lived.\n\nYou want `fixup -C` in the todo-list. See the hints near the end of the\ntodo-list.\n\n-- Hannes\n"},{"id":"451683","messageId":"YjcHlf3Tyvq+vazm@ugly","threadId":"57586","inReplyTo":"9fae5292-d58f-95da-245b-6e205383cb50@kdbg.org","subject":"Re: using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2022-03-20T10:53:09Z","receivedAt":"2022-03-20T10:53:17Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Sun, Mar 20, 2022 at 09:05:45AM +0100, Johannes Sixt wrote:\n>You want `fixup -C` in the todo-list. See the hints near the end of the\n>todo-list.\n>\noh, cool, thanks. i didn't expect to find it _there_. :}\n\nnote that neither the man page nor the inline comment mention either \n\"date\" or \"timestamp\". of course that seems redundant when one knows how \ncommit -C works, but it's not helpful for discoverability by keywords.\n"},{"id":"483761","messageId":"a99b16a8-a06c-4d38-bb78-46ce17411597@gmail.com","threadId":"57586","inReplyTo":"9fae5292-d58f-95da-245b-6e205383cb50@kdbg.org","subject":"Re: using oldest date when squashing commits","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-10-24T09:26:29Z","receivedAt":"2023-10-24T09:26:57Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 20/03/2022 08:05, Johannes Sixt wrote:\n> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:\n>> during interactive rebasing, i sometimes find it necessary to move a\n>> hunk from one commit to a later one in the branch. now, if that hunk\n>> cannot be re-ordered with the later commit due to conflicting with it,\n>> it becomes necessary to squash the later commit onto a temporary commit\n>> created from the extracted hunk, not the other way around (or using a\n>> stash). unfortunately, this causes the author date of the later commit\n>> to be reset, which can rather seriously falsify the date if the branch\n>> is long-lived.\n> \n> You want `fixup -C` in the todo-list. See the hints near the end of the\n> todo-list.\n\nUnfortunately \"fixup -C\" only copies the commit message not the \nauthorship (that's usually a good thing but not it means it wont work \nfor what Oswald wants to do). Maybe we should add another flag for \nfixup/squash commands to take the authorship from that commit. In the \nmeantime creating the temporary commit with \"git commit -C\" is probably \nthe easiest way to keep the original authorship.\n\nBest Wishes\n\nPhillip\n"},{"id":"483762","messageId":"ZTeZ3KEQLIVU/sq2@ugly","threadId":"57586","inReplyTo":"a99b16a8-a06c-4d38-bb78-46ce17411597@gmail.com","subject":"Re: using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2023-10-24T10:18:04Z","receivedAt":"2023-10-24T10:18:09Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Tue, Oct 24, 2023 at 10:26:29AM +0100, Phillip Wood wrote:\n>On 20/03/2022 08:05, Johannes Sixt wrote:\n>> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:\n>>> during interactive rebasing, i sometimes find it necessary to move a\n>>> hunk from one commit to a later one in the branch. now, if that hunk\n>>> cannot be re-ordered with the later commit due to conflicting with it,\n>>> it becomes necessary to squash the later commit onto a temporary commit\n>>> created from the extracted hunk, not the other way around (or using a\n>>> stash). unfortunately, this causes the author date of the later commit\n>>> to be reset, which can rather seriously falsify the date if the branch\n>>> is long-lived.\n>> \n>> You want `fixup -C` in the todo-list. See the hints near the end of the\n>> todo-list.\n>\n>Unfortunately \"fixup -C\" only copies the commit message not the \n>authorship\n\n>(that's usually a good thing\n>\nwhy? what would that be useful for? it seems rather counter-intuitive.\nit's also inconsistent with commit -c/-C's behavior, which seems like a \nred flag to me.\n\n>but not it means it wont work for what Oswald wants to do).\n\n>Maybe we should add another flag for fixup/squash commands to take the \n>authorship from that commit.\n>\nthat's a possibility. but given the above, it might be better to simply \nchange the behavior of -c/-C to keep the UI lean and consistent with \ncommit's behavior.\n\nregards\n"},{"id":"483784","messageId":"138631cd-ead3-4f22-95ce-61afccfa409f@gmail.com","threadId":"57586","inReplyTo":"ZTeZ3KEQLIVU/sq2@ugly","subject":"Re: using oldest date when squashing commits","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2023-10-24T14:00:58Z","receivedAt":"2023-10-24T14:01:04Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 24/10/2023 11:18, Oswald Buddenhagen wrote:\n> On Tue, Oct 24, 2023 at 10:26:29AM +0100, Phillip Wood wrote:\n>> On 20/03/2022 08:05, Johannes Sixt wrote:\n>>> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:\n>>>> during interactive rebasing, i sometimes find it necessary to move a\n>>>> hunk from one commit to a later one in the branch. now, if that hunk\n>>>> cannot be re-ordered with the later commit due to conflicting with it,\n>>>> it becomes necessary to squash the later commit onto a temporary commit\n>>>> created from the extracted hunk, not the other way around (or using a\n>>>> stash). unfortunately, this causes the author date of the later commit\n>>>> to be reset, which can rather seriously falsify the date if the branch\n>>>> is long-lived.\n>>>\n>>> You want `fixup -C` in the todo-list. See the hints near the end of the\n>>> todo-list.\n>>\n>> Unfortunately \"fixup -C\" only copies the commit message not the \n>> authorship\n> \n>> (that's usually a good thing\n>>\n> why? what would that be useful for?\n > it seems rather counter-intuitive.\n\nIn the same way that you do not want to change the author date when \nusing a fixup to move a small hunk from one commit to another most users \ndo not want to update the author information when they make a small \nchange to a commit message using \"fixup -C\"\n\n> it's also inconsistent with commit -c/-C's behavior, which seems like a \n> red flag to me.\n\nThat could mean the option is mis-named instead rather than the behavior \nbeing wrong.\n\n>> but not it means it wont work for what Oswald wants to do).\n> \n>> Maybe we should add another flag for fixup/squash commands to take the \n>> authorship from that commit.\n>>\n> that's a possibility. but given the above, it might be better to simply \n> change the behavior of -c/-C to keep the UI lean and consistent with \n> commit's behavior.\n\n\"fixup -c/-C\" were conceived as a way to reword a commit message at the \nsame time as optionally fixing up the commit's content. I think changing \nthe behavior to automatically update the authorship would surprise \npeople and as I said above most of the time one does not want that behavior.\n\nBest Wishes\n\nPhillip\n"},{"id":"483799","messageId":"xmqqpm143p46.fsf@gitster.g","threadId":"57586","inReplyTo":"138631cd-ead3-4f22-95ce-61afccfa409f@gmail.com","subject":"Re: using oldest date when squashing commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-24T17:30:01Z","receivedAt":"2023-10-24T17:30:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n>>> Unfortunately \"fixup -C\" only copies the commit message not the\n>>> authorship\n>> \n>>> (that's usually a good thing\n>>>\n>> why? what would that be useful for?\n>> it seems rather counter-intuitive.\n>\n> In the same way that you do not want to change the author date when\n> using a fixup to move a small hunk from one commit to another most\n> users do not want to update the author information when they make a\n> small change to a commit message using \"fixup -C\"\n\nExactly.\n\nIt would be OK to add \"fixup -c --reset-author\", but the default\nshould stay.  In addition, I wouldn't be able to use \"rebase -i\" to\nmake typofixes to commits made out of received patches if the\noperation changes the authorship.\n\n> \"fixup -c/-C\" were conceived as a way to reword a commit message at\n> the same time as optionally fixing up the commit's content.\n\nYup, it still is a \"fix\", meaning the identity and the spirit of the\ncommit being fixed are unchanged.  What it aims to achieve, how it\nimplements the behaviour it wants to give its users, who thought of\nthat change, all that are the same as the original.  It may be a\nnice addition to optionally allow users to use --reset-author (or\nbetter yet, --author=\"Na Me <a@dd.re.ss>\") with \"fixup\", but if the\n\"-c\" variant can be concluded with \"commit --amend --reset-author\"\nto achieve the same effect, that may be sufficient.\n\nThanks.\n\n\n"},{"id":"483815","messageId":"ZTglW0fQnSTV+TnD@ugly","threadId":"57586","inReplyTo":"xmqqpm143p46.fsf@gitster.g","subject":"Re: using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2023-10-24T20:13:15Z","receivedAt":"2023-10-24T20:13:21Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Tue, Oct 24, 2023 at 10:30:01AM -0700, Junio C Hamano wrote:\n>Phillip Wood <phillip.wood123@gmail.com> writes:\n>>>> Unfortunately \"fixup -C\" only copies the commit message not the\n>>>> authorship\n>>> \n>>>> (that's usually a good thing\n>>>>\n>>> why? what would that be useful for?\n>>> it seems rather counter-intuitive.\n>>\n>> In the same way that you do not want to change the author date when\n>> using a fixup to move a small hunk from one commit to another most\n>> users do not want to update the author information when they make a\n>> small change to a commit message using \"fixup -C\"\n>\n>Exactly. [...]\n>I wouldn't be able to use \"rebase -i\" to\n>make typofixes to commits made out of received patches if the\n>operation changes the authorship.\n>\n>> \"fixup -c/-C\" were conceived as a way to reword a commit message at\n>> the same time as optionally fixing up the commit's content.\n>\n>Yup, it still is a \"fix\", meaning the identity and the spirit of the\n>commit being fixed are unchanged.  What it aims to achieve, how it\n>implements the behaviour it wants to give its users, who thought of\n>that change, all that are the same as the original.\n>\nok, i think i finally got it. it would have never ocurred to me to make \na command for that - i just use \"squash\" and throw away the extra lines.  \nbut i guess it sort of makes sense if you use rebase as a \nnon-interactive execution backend for instructions that are fully \ndetermined long in advance by heaping commits at the end.\n\n> It may be a nice addition to optionally allow users to use \n> --reset-author (or better yet, --author=\"Na Me <a@dd.re.ss>\") with \n> \"fixup\"\n>\nthat's kind of the opposite of what i'd want - the \"pre-fixup\" commit \nalready has the equivalent of that by virtue of being fresh. so it would \nbe more like --copy-author. but i'd go with adding -ca/-CA variants \ninstead, for brevity.\n\n>but if the \"-c\" variant can be concluded with \"commit --amend \n>--reset-author\" to achieve the same effect, that may be sufficient.\n>\nfrom the above follows that the equivalent of my original request would \nbe appending \"exec git commit --amend -C <orig>\" to the \"pick \n<pre-fixup>\" + \"fixup <orig>\" commands. which is of course horrible, and \ni'd never remember to actually do that. it will be hard enough to \nretrain myself to use -CA instead of -C.\n\nregards\n\n"},{"id":"483821","messageId":"59731c05-c3f6-4815-8411-783bb1c2aac4@kdbg.org","threadId":"57586","inReplyTo":"xmqqpm143p46.fsf@gitster.g","subject":"Re: using oldest date when squashing commits","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2023-10-24T21:19:53Z","receivedAt":"2023-10-24T21:20:18Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 24.10.23 um 19:30 schrieb Junio C Hamano:\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n>> \"fixup -c/-C\" were conceived as a way to reword a commit message at\n>> the same time as optionally fixing up the commit's content.\n> \n> Yup, it still is a \"fix\", meaning the identity and the spirit of the\n> commit being fixed are unchanged.\n\nThat's a pitty, because that is not at all what *I* use \"fixup -C\" for.\nTo update the commit message, I use \"squash\" (or occasionally \"reword\").\nI use \"fixup -C\" after the following events:\n\n1. Commit unfinished changes for whatever reason. Usually the commit\nmessage just says \"WIP <topic>\" because that's what it is.\n2. Make a fixup commit for an earlier commit because doing the fixup now\ngets it out of the way, and often delaying it until after the completed\nchange would cause merge conflicts.\n3. Complete the WIP including the commit message.\n\nI would now use \"fixup -C\" on commit 3, because its metadata reflects\nreality more accurately than that of 1. Commit 3 often comes days after 1.\n\n-- Hannes\n\n"},{"id":"483977","messageId":"70b8d4d8-f4b5-4cd7-b73a-1d7393d84266@xiplink.com","threadId":"57586","inReplyTo":"59731c05-c3f6-4815-8411-783bb1c2aac4@kdbg.org","subject":"Re: using oldest date when squashing commits","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2023-10-27T12:34:40Z","receivedAt":"2023-10-27T12:34:46Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2023-10-24 17:19, Johannes Sixt wrote:\n> Am 24.10.23 um 19:30 schrieb Junio C Hamano:\n>> Phillip Wood <phillip.wood123@gmail.com> writes:\n>>> \"fixup -c/-C\" were conceived as a way to reword a commit message at\n>>> the same time as optionally fixing up the commit's content.\n>>\n>> Yup, it still is a \"fix\", meaning the identity and the spirit of the\n>> commit being fixed are unchanged.\n> \n> That's a pitty, because that is not at all what *I* use \"fixup -C\" for.\n> To update the commit message, I use \"squash\" (or occasionally \"reword\").\n> I use \"fixup -C\" after the following events:\n> \n> 1. Commit unfinished changes for whatever reason. Usually the commit\n> message just says \"WIP <topic>\" because that's what it is.\n> 2. Make a fixup commit for an earlier commit because doing the fixup now\n> gets it out of the way, and often delaying it until after the completed\n> change would cause merge conflicts.\n> 3. Complete the WIP including the commit message.\n> \n> I would now use \"fixup -C\" on commit 3, because its metadata reflects\n> reality more accurately than that of 1. Commit 3 often comes days after 1.\n\nSpeaking of the metadata ...\n\nI never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I find \nthat I would prefer it if Git used the most recent Author date from the \nset of commits being combined, rather than preserving the picked \ncommit's Author date.  Sometimes it takes quite a while for me to get a \npiece of work sorted out, and I would rather have the Author date in the \nend-result commit reflect the work's completion time than its initiation \ntime.\n\nThe current behaviour means that when scanning through commits with \ntools like gitk (which shows just the Author date in its list of \ncommits) I'll often see what I feel are inaccurate or confusing dates \nthere, and I use the Committer date (a bit less convenient in gitk) to \nfigure out when the work was actually \"done\".  (Although the span \nbetween the Author date from the start of the work and the Committer \ndate from the end of the work would roughly reflect how long the work \ntook to complete, I don't use Git for that kind of information.)\n\nAnyway, this is a minor itch for me that I've never felt the need to \nscratch.  I just thought I'd mention it since the topic is being discussed.\n\n\t\tM.\n"},{"id":"483980","messageId":"ZTuw7ziOnTunMmML@ugly","threadId":"57586","inReplyTo":"70b8d4d8-f4b5-4cd7-b73a-1d7393d84266@xiplink.com","subject":"Re: using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2023-10-27T12:45:35Z","receivedAt":"2023-10-27T12:45:45Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:\n>I never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I \n>find that I would prefer it if Git used the most recent Author date \n>from the set of commits being combined, rather than preserving the \n>picked commit's Author date.\n>\nthat would be unreliable, as plain amends wouldn't be reflected. that \nmay be rare in your workflow, but still.\n\n>Sometimes it takes quite a while for me to get a piece of work sorted \n>out, and I would rather have the Author date in the end-result commit \n>reflect the work's completion time than its initiation time.\n>\nafaict, you need to get used to `--amend --reset-author` all commits \nbefore you push to achieve this reliably. that can be easily automated \nby using -x with rebase -i (filter-repo (ex filter-branch) would also \nwork).\n\nregards\n"},{"id":"483988","messageId":"6d100655-ffd4-4282-87b5-cfdd101dba63@xiplink.com","threadId":"57586","inReplyTo":"ZTuw7ziOnTunMmML@ugly","subject":"Re: using oldest date when squashing commits","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2023-10-27T13:20:04Z","receivedAt":"2023-10-27T13:20:09Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2023-10-27 08:45, Oswald Buddenhagen wrote:\n> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:\n>> I never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I \n>> find that I would prefer it if Git used the most recent Author date \n>> from the set of commits being combined, rather than preserving the \n>> picked commit's Author date.\n>>\n> that would be unreliable, as plain amends wouldn't be reflected. that \n> may be rare in your workflow, but still.\n\nI'm not talking about amends, plain or otherwise.  I'm talking about \nfixup/squash.\n\n(Why do you focus so much an making rebase and commit behave \nidentically?  There is no reason to do so just because they happen to \nshare a couple of parameter names.)\n\n>> Sometimes it takes quite a while for me to get a piece of work sorted \n>> out, and I would rather have the Author date in the end-result commit \n>> reflect the work's completion time than its initiation time.\n>>\n> afaict, you need to get used to `--amend --reset-author` all commits \n> before you push to achieve this reliably. that can be easily automated \n> by using -x with rebase -i (filter-repo (ex filter-branch) would also \n> work).\n\nYes, I know how to force my desired author date on commits, thanks.\n\n\t\tM.\n"},{"id":"483989","messageId":"ZTu6cqUec3L2PpUC@ugly","threadId":"57586","inReplyTo":"6d100655-ffd4-4282-87b5-cfdd101dba63@xiplink.com","subject":"Re: using oldest date when squashing commits","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2023-10-27T13:26:10Z","receivedAt":"2023-10-27T13:26:18Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Fri, Oct 27, 2023 at 09:20:04AM -0400, Marc Branchaud wrote:\n>\n>On 2023-10-27 08:45, Oswald Buddenhagen wrote:\n>> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:\n>>> I never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I \n>>> find that I would prefer it if Git used the most recent Author date \n>>> from the set of commits being combined, rather than preserving the \n>>> picked commit's Author date.\n>>>\n>> that would be unreliable, as plain amends wouldn't be reflected. that \n>> may be rare in your workflow, but still.\n>\n>I'm not talking about amends, plain or otherwise.\n>\nbut why wouldn't you? your use case of marking the date of completion \nnaturally covers all ways of amending commits, whether directly or via \nsquashing.\n\nregards\n"},{"id":"483991","messageId":"3aff8ce6-1cb0-465e-9b7a-db6473713786@xiplink.com","threadId":"57586","inReplyTo":"ZTu6cqUec3L2PpUC@ugly","subject":"Re: using oldest date when squashing commits","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2023-10-27T13:46:06Z","receivedAt":"2023-10-27T13:46:12Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2023-10-27 09:26, Oswald Buddenhagen wrote:\n> On Fri, Oct 27, 2023 at 09:20:04AM -0400, Marc Branchaud wrote:\n>>\n>> On 2023-10-27 08:45, Oswald Buddenhagen wrote:\n>>> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:\n>>>> I never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I \n>>>> find that I would prefer it if Git used the most recent Author date \n>>>> from the set of commits being combined, rather than preserving the \n>>>> picked commit's Author date.\n>>>>\n>>> that would be unreliable, as plain amends wouldn't be reflected. that \n>>> may be rare in your workflow, but still.\n>>\n>> I'm not talking about amends, plain or otherwise.\n>>\n> but why wouldn't you? your use case of marking the date of completion \n> naturally covers all ways of amending commits, whether directly or via \n> squashing.\n\nPlease do not presume what my use cases might be.  I'm quite happy with \ncommit's behaviour, but not happy with rebase's fixup/squash behaviour \nbecause it's too much work to achieve the desired results.  (Results \nwhich, as I said, I don't care about enough to bother changing anyway).\n\n\t\tM.\n"},{"id":"484008","messageId":"xmqqlebnodh6.fsf@gitster.g","threadId":"57586","inReplyTo":"70b8d4d8-f4b5-4cd7-b73a-1d7393d84266@xiplink.com","subject":"Re: using oldest date when squashing commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-27T23:24:53Z","receivedAt":"2023-10-27T23:24:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud <marcnarc@xiplink.com> writes:\n\n> I never use \"fixup -C\" (or -c), but I do use squash/fixup a lot.  I\n> find that I would prefer it if Git used the most recent Author date\n> from the set of commits being combined, rather than preserving the\n> picked commit's Author date.  Sometimes it takes quite a while for me\n> to get a piece of work sorted out, and I would rather have the Author\n> date in the end-result commit reflect the work's completion time than\n> its initiation time.\n\nYeah, I can sympathize but with both positions, as I can see why\nmost people would want \"minor fixups and typofixes\" to retain the\noriginal authorship date, and when concluding a \"combining the whole\nsteps together to reach this final single patch\" development, they\nwould want to record the completion date.  The \"take the one's\nauthorship and apply only the effects and not metadata from the\nfixups\" is a good match for the former.  To support the latter, we\ncan just ignore the timestamp of any commits that were involved in\nthe end result, and record the time \"rebase -i\" was concluded\ninstead, but the tool is not set up for doing so.\n\n> The current behaviour means that when scanning through commits with\n> tools like gitk (which shows just the Author date in its list of\n> commits) I'll often see what I feel are inaccurate or confusing dates\n> there,...\n\nYup, exactly.  Two opposing worldviews, which is not even per-user,\nbut depends on why the \"fixup/squash\" was used, exists, but the tool\nwas designed to support the \"small fixup for work that was mostly\ndone already\" use case, so the other usecase is left for people to\nsay \"Yes, I know how to force my desired author date on commits,\nthanks.\" ;-)\n\n> Anyway, this is a minor itch for me that I've never felt the need to\n> scratch.  I just thought I'd mention it since the topic is being\n> discussed.\n\nYup, it is a very good observation.  Giving it a good UI to support\nboth worldviews would be a good exercise, as we all need both\nbehaviour from time to time.\n\nThanks.\n"}]}