What is the safest way to correct the date of a future-dated commit in git, and what are the consequences?

Question

A developer managed to commit some code with a future date--March 1, 2013, to be exact

git show --format=fuller <SHA>

AuthorDate: Fri Mar 1 17:28:26 2013 +0300
CommitDate: Fri Mar 1 17:29:38 2013 +0300

This is (a) misleading, and (b) blocking Jira from finding "new" commits that are tagged with Jira ticket numbers (there have been no commits since Mar 1, 2013--and won't be for 6 months yet)

I have found examples of how to use git filter-branch to correct the date, e.g. http://git.661346.n2.nabble.com/date-change-of-commit-td3887606.html :

git filter-branch --env-filter ' 
  if [ $GIT_COMMIT = <sha1> ]; then 
    export GIT_AUTHOR_DATE="1112911993 -0700" 
    export GIT_COMMITTER_DATE="1112911993 -0700" 
  fi 
'

But they come with warnings of dire consequences. Answers to any one or more of the following questions would be appreciated.

• What is your experience using the above method to change a commit date?
• What are the consequences to others using the repository?
• What are the consequences to outstanding feature or deployment branches off of the main branch?
• Is there any better way to do this?

Answer 1

The sha1 of any given commit is based on all the information associated with that commit, including the date, and the history of all commits before it, back to the beginning of the project. This makes it so someone cannot maliciously change a repository without everyone noticing. It also makes it so someone cannot benevolently change a repository without everyone noticing.

Doing the filter-branch essentially deletes the branch up until the commit before the bad commit, and creates a completely new branch starting from that point. If any branch was created after that point, it will have to be rebased. If anyone has pulled since that point, they will have to do a force pull. No, there is no less disruptive way around it, except maybe hacking Jira to do what you want until March.