Updating commit timestamp on rebase [was: Updating commit timestamp on push.]

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Dec 11 05:28:22 UTC 2013


On 12/10/2013 07:42 AM, Augie Fackler wrote:
> On Fri, Dec 06, 2013 at 12:59:04AM +0000, Kannan Goundan wrote:
>> Thanks everyone for the words of caution about my "update timestamp on push"
>> idea :)
>>
>> I went with a different approach: I modified rebase to always use the
>> current timestamp when rewriting a patch (instead of using the timestamp of
>> the original commit).  This seems simpler and safer than my original idea,
>> but still achieves the goal of having the commit timestamp roughly match the
>> push timestamp (we rebase before pushing to the central repo).
>>
>> Unfortunately the implementation is hacky.  I wrote an extension that
>> monkey-patches hgext.rebase.concludenode and discards the "date" parameter
>> to repo.commit().  Roughly:
>>
>>     def patched_concludenode(repo, ...)
>>         repo = RepoWrapper(repo)
>>         orig_concludenode(repo, ...)
>>
>>     class RepoWrapper(object):
>>         def __init__(self, repo):
>>             self._original_repo = repo
>>         def commit(self, ..., date=None, ...):
>>             self._original_repo.commit(..., date=None, ...)
>>         ...
>>         # Forward all the other methods through unchanged.
>>
>> I'm a little worried about this breaking in weird corner cases or for new
>> Mercurial releases.  Any ideas on how to do this more robustly?
>>
>> In general, I think having "rebase" update the commit date is useful.  If
>> others feel the same way, maybe the rebase extension could be modified to
>> support it directly, possibly through an option in hgrc?  Any objections to
>> that idea?
> I'm open to it. How do other people feel?

I do not like the idea. I prefer changeset date to refers to the date 
the core work was done.  a last rebase is very likely to happen at the 
last integration stage. So you would basically end up with date == date 
is was accepted. instead of date it was created. break a lot of date use 
case in my eyes (First one is ability to know what I've been doing last 
week).

-- 
Pierre-Yves David




More information about the Mercurial mailing list