{"thread":{"id":"50989","subject":"Request to add option to interactive rebase to preserve latest commit date","startedAt":"2019-04-25T13:00:47Z","lastAt":"2019-05-10T16:57:39Z","messageCount":7,"participants":["Jeff Schwartz","Junio C Hamano","Peter Krefting","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"374499","messageId":"CAL3M-FZ7b3H7Z+Vr9Wbey5iYVoWiUBnDKVEenyAMrUXeNfL56w@mail.gmail.com","threadId":"50989","inReplyTo":null,"subject":"Request to add option to interactive rebase to preserve latest commit date","fromName":"Jeff Schwartz","fromEmail":"jefftschwartz@gmail.com","sentAt":"2019-04-25T13:00:07Z","receivedAt":"2019-04-25T13:00:47Z","isPatch":false,"sender":{"key":"jefftschwartz@gmail.com","avatar":null},"body":"Using interactive rebase has one flaw IMHO and that is the way it\nhandles dating its commit. Can you add an option to interactive rebase\nthat would make it use the date from the commit that is most recent\nand not the date from the commit that is the oldest?\n\n-\n*Jeff*\n"},{"id":"374561","messageId":"xmqq4l6kvnuu.fsf@gitster-ct.c.googlers.com","threadId":"50989","inReplyTo":"CAL3M-FZ7b3H7Z+Vr9Wbey5iYVoWiUBnDKVEenyAMrUXeNfL56w@mail.gmail.com","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-04-26T14:32:25Z","receivedAt":"2019-04-26T14:32:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Schwartz <jefftschwartz@gmail.com> writes:\n\n> Using interactive rebase has one flaw IMHO and that is the way it\n> handles dating its commit. Can you add an option to interactive rebase\n> that would make it use the date from the commit that is most recent\n> and not the date from the commit that is the oldest?\n\nI am not sure what you mean by this.  If you interactively rebase\nthe topmost two commits (assuming that since three commits ago, you\nhave a linear history):\n\n\t$ git rebase -i HEAD~2\n\nand tell the editor that you want to 'edit' both instead of just\n'pick'ing, the command will give you control back for both of these\ntwo commits, and you can say \"git rebase --continue\".\n\n\n    o----X----Y (original history)\n     \\\n      \\\n       X'----Y' (rebased history)\n\nAfter the exercise, the two new commits that replaced the two\ncommits from the original history\n\n (1) retain their own author timestamp; and\n\n (2) record the time when these new commits are created as the\n     committer timestamp.\n\nSo there is no \"most recent\" or \"oldest\" timestamp in the series\ninvolved.  The author timestamp of commit X' (which corresponds to\nthe commit X in the original history) in the rewritten history is\nthe same as the author timestamp of commit X.  Same for the author\ntimestamps of commit Y and Y'.\n\nThe committer timestamp of commit X' and commit Y' are the actual\ntime each step of your \"rebase -i\" operation creates them, which\nshould be more recent than those of commit X and commit Y, unless\nyour clock or the clock on the machine on which X and Y were created\nare not in sync with the real world.\n\n"},{"id":"374739","messageId":"alpine.DEB.2.20.1905010900260.23829@perkele.intern.softwolves.pp.se","threadId":"50989","inReplyTo":"xmqq4l6kvnuu.fsf@gitster-ct.c.googlers.com","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2019-05-01T08:52:32Z","receivedAt":"2019-05-01T08:59:46Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Junio C Hamano:\n\n>> Using interactive rebase has one flaw IMHO and that is the way it\n>> handles dating its commit. Can you add an option to interactive rebase\n>> that would make it use the date from the commit that is most recent\n>> and not the date from the commit that is the oldest?\n>\n> I am not sure what you mean by this.  If you interactively rebase\n> the topmost two commits (assuming that since three commits ago, you\n> have a linear history):\n\nI sort of assume that this is when merging several fixup! or squash! \ncommits. I often end up adding lines the code to date these with the \ncurrent date, but the date of the last fixup'ed or squash'ed commit \nwould probably be better.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"374983","messageId":"xmqqtve6nbfv.fsf@gitster-ct.c.googlers.com","threadId":"50989","inReplyTo":"alpine.DEB.2.20.1905010900260.23829@perkele.intern.softwolves.pp.se","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-07T04:19:32Z","receivedAt":"2019-05-07T04:19:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Krefting <peter@softwolves.pp.se> writes:\n\n> Junio C Hamano:\n>\n>>> Using interactive rebase has one flaw IMHO and that is the way it\n>>> handles dating its commit. Can you add an option to interactive rebase\n>>> that would make it use the date from the commit that is most recent\n>>> and not the date from the commit that is the oldest?\n>>\n>> I am not sure what you mean by this.  If you interactively rebase\n>> the topmost two commits (assuming that since three commits ago, you\n>> have a linear history):\n>\n> I sort of assume that this is when merging several fixup! or squash!\n> commits. I often end up adding lines the code to date these with the\n> current date, but the date of the last fixup'ed or squash'ed commit\n> would probably be better.\n\nAh, I see.  So if you have (time flows left to right, as usual):\n\n\tA---B---C\n\nwhere B and C are fixup for A, the question is what's the author\nident and author time should be for the resulting single commit.\n\nI think we currently use the ident and time from the original A, and\nthat is the only right thing to do, as I view\n\n\t$ git commit -m A\n\t$ edit\n\t$ git commit -a --fixup HEAD ;# create B to fix A\n\t$ edit\n\t$ git commit -a --fixup HEAD^ ;# create C to fix A\n\t$ git rebase --autosquash -i HEAD~3 ;# squash B and C into A\n\nas merely a different way to do the following:\n\n\t$ git commit -m A\n\t$ edit\n\t$ edit further ;# working tree has an equivalent of C\n\t$ git commit --amend -a\n\nThe principle is \"the bulk of the work was done in A, no matter what\nis done incrementally by squashing in or amending small refinements;\nthe primary authorship date and time stays the same as the original\".\n\nWhen the person who is correcting other's change with --amend makes\na contribution that is substantial enough such that the amended HEAD\nno longer resembles the original HEAD, there is a mechanism to let\nthe amender take authorship, i.e. do this at the last step instead\n\n\t$ git commit --reset-author --amend -a\n\nin the second sequence.  I do not think there currently is an\nequivalent in \"rebase -i\" language to do so.  \n\nI am still not convinced it is a good idea, but I can see how\nanother verb that behaves like existing \"fixup\" or \"squash\" but use\nthe authorship not from the updated but from the updating commit\nmight seem useful.\n"},{"id":"374988","messageId":"alpine.DEB.2.20.1905070641380.1748@perkele.intern.softwolves.pp.se","threadId":"50989","inReplyTo":"xmqqtve6nbfv.fsf@gitster-ct.c.googlers.com","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2019-05-07T05:45:05Z","receivedAt":"2019-05-07T05:45:23Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Junio C Hamano:\n\n> as merely a different way to do the following:\n>\n> \t$ git commit -m A\n> \t$ edit\n> \t$ edit further ;# working tree has an equivalent of C\n> \t$ git commit --amend -a\n\nIndeed. My last command in the chain is usually\n\n   git commit --amend --date=now\n\nto set the commit date to now. In my use-case it is often a \nwork-in-progress commit that I start out with, which I refine over a \ncouple of hours/days/weeks to get working properly (depending on the \ncomplexity of the change), and when I am finally done, the proper \ndating of the change is \"now\", not \"when I first started doing it\".\n\n> I am still not convinced it is a good idea, but I can see how \n> another verb that behaves like existing \"fixup\" or \"squash\" but use \n> the authorship not from the updated but from the updating commit \n> might seem useful.\n\nI'd be happy with a parameter and/or configuration variable saying \n\"amend and rebase uses last commit date\".\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"375012","messageId":"CAL3M-FamUTpygCWfi_EK7k59TsaG7zo5qu-zQTeBQ3WwY1g+hA@mail.gmail.com","threadId":"50989","inReplyTo":"alpine.DEB.2.20.1905070641380.1748@perkele.intern.softwolves.pp.se","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Jeff Schwartz","fromEmail":"jefftschwartz@gmail.com","sentAt":"2019-05-07T10:52:54Z","receivedAt":"2019-05-07T10:53:32Z","isPatch":false,"sender":{"key":"jefftschwartz@gmail.com","avatar":null},"body":"Yes, exactly. When squashing or fixup-ing commits via rebase I really\nwant \"git log\" to show the date and time of the rebase operation and\nnot the date and time of the commit I rebased onto, which could be\nmonths or even years in the past. I once worked on a project where\npart of the code-base hadn't been touched in over a year. After\nperforming a number of WIPs on it over a 4 month period I cleaned up\nthe final commit using interactive rebase, squashing all the WIPs into\na single commit whose message reflected the actual scope of the\nchanges that had been made. A naive project manager with limited\nunderstanding of Git other than how to use 'git log' to oversee what\nus developers have been up to time-wise was enraged that we had\ncommitted changes months back and appeared to have done nothing since\nthen. I believe that by adding an option to\n'rebase -i hash' that would apply the current date and time of the\noperation would be an awesome addition to Git and its user base.\n\n*Jeff*\n\nOn Tue, May 7, 2019 at 1:45 AM Peter Krefting <peter@softwolves.pp.se> wrote:\n>\n> Junio C Hamano:\n>\n> > as merely a different way to do the following:\n> >\n> >       $ git commit -m A\n> >       $ edit\n> >       $ edit further ;# working tree has an equivalent of C\n> >       $ git commit --amend -a\n>\n> Indeed. My last command in the chain is usually\n>\n>    git commit --amend --date=now\n>\n> to set the commit date to now. In my use-case it is often a\n> work-in-progress commit that I start out with, which I refine over a\n> couple of hours/days/weeks to get working properly (depending on the\n> complexity of the change), and when I am finally done, the proper\n> dating of the change is \"now\", not \"when I first started doing it\".\n>\n> > I am still not convinced it is a good idea, but I can see how\n> > another verb that behaves like existing \"fixup\" or \"squash\" but use\n> > the authorship not from the updated but from the updating commit\n> > might seem useful.\n>\n> I'd be happy with a parameter and/or configuration variable saying\n> \"amend and rebase uses last commit date\".\n>\n> --\n> \\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"375304","messageId":"412f07c2-3ab2-0902-89bd-21e8fe8dc190@iee.org","threadId":"50989","inReplyTo":"xmqqtve6nbfv.fsf@gitster-ct.c.googlers.com","subject":"Re: Request to add option to interactive rebase to preserve latest commit date","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-05-10T16:57:35Z","receivedAt":"2019-05-10T16:57:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 07/05/2019 05:19, Junio C Hamano wrote:\n> The principle is \"the bulk of the work was done in A, no matter what\n> is done incrementally by squashing in or amending small refinements;\n> the primary authorship date and time stays the same as the original\".\n>\n> When the person who is correcting other's change with --amend makes\n> a contribution that is substantial enough such that the amended HEAD\n> no longer resembles the original HEAD, there is a mechanism to let\n> the amender take authorship,\nIIUC the effective change in authorship was noted in another thread \nabout a perceived problem in rebase, and it just bit me as well recently \n(and the Github PR bot rejected my series for a mismatched \nauthor/sign-off :-(.\n\nIf a commit is edited in a `rebase -i` then I think the same can happen, \nresulting in the same user surprise at the change. Possibly a simple \ndocumentation note may help reduce user surprise.\n> i.e. do this at the last step instead\n>\n> \t$ git commit --reset-author --amend -a\n>\n> in the second sequence.  I do not think there currently is an\n> equivalent in \"rebase -i\" language to do so.\n--\nPhilip\n"}]}