I often use histedit to fold commits when I've realised I've forgotten something that should be in the original commit. However when I fold the update, the timestamp of the original commit isn't preserved. I think there should be a switch to allow timestamp preservation. This is similar to what MQ allows by setting a date when updating a patch. However I find using histedit is quicker to fold an update into a commit.
We should probably take the date of the most recent commit by default (either topologically or numerically).
While a fold should keep the most recent date (as per current behaviour), can an "amend" option be added to histedit? This would do a fold and preserve the existing commit timestamp, much like commit --amend does.
Created attachment 1907 [details] Patch adding 'amnd' action against v3.2.4.
Created attachment 1908 [details] Patch adding 'amnd' action against 62e73d42bd14 (yesterday's tip)
I'm interested in this behaviour too. I have prepared a patch which adds an 'amnd' action against v3.2.4 as well as against yesterday's tip (62e73d42bd14). Perhaps rather than adding a new option, though, it would make sense to adjust the behaviour of 'roll'. After all, 'roll' discards the commit message of the later commit, using that of the first; it would make sense for it also to keep the date of the first commit, discarding the date of the later one. It would be even easier to prepare a path to do this. Would one of these options be considered?
We don't accept patches via the BTS, sorry.
Sorry. A page on the wiki led me to believe you did: <https://www.mercurial-scm.org/wiki/CrewHowTo#Accepting_patches>. It took me quite some time/clicks to even get there from www.mercurial-scm.org and I probably didn't read it fully enough before throwing something up here. Not to worry. I've now found https://www.mercurial-scm.org/wiki/ContributingChanges and can follow its advice. However, I was hoping for an indication of whether one of the options outlined would be acceptable, and which might be preferred. E.g. can we put changing the 'roll' action on the table, or would that be considered an unacceptable change/BC break? Or should this be asked on mercurial-devel as well, instead of here? Unfortunately, your previous comment, though somewhat informative, didn't actually give me any *useful* information on how to move forward. From my perspective, a few words spent telling me where I *should* go and where you *do* accept patches would have been much more valuable than words spent telling me what you don't do.
(Many years of experience has shown that linking people to ContributingChanges rarely "works" either.) If I look at your patches here (a headache, because browsers in 2016 apparently don't know how to view text/plain) and have comments (likely), I can't usefully insert them. So I just have to say "there are problems, go to the list for feedback".. at which point I or someone else will have to redo the work of looking at them. Ergo, no one ever even looks at patches on the BTS.
Bug was inactive for 150 days, archiving
Following discussion on the mailing list, I am still intending to address this. However, I happened to hit code freeze last time, and then personal circumstances prevented me from supplying the patch after that. It will happen, just not as quickly as Bugzilla would like.
@Ben Schmidt Did you find some time to post it? I like to see this feature, too. We use a hash of "date / author" as a simple identifier for code review on a reviewboard. So this would help us a lot.
For the record, this landed in the form of modifying the 'rollup' histedit command to discard the date of the second commit. https://www.mercurial-scm.org/repo/hg/rev/f1b63ec4b987 https://www.mercurial-scm.org/repo/hg/rev/37ab9e20991c
The OP asked me which version this landed in. I think it was 4.2.