5

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?
Kevin Kohrt
  • 226
  • 2
  • 5

2 Answers2

2

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.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
0

The consequences aren't that dire. It will simply be that anyone who has pulled that branch with the bad commits may need to take extra steps after you push the fix, since you'll be replacing the commits that are there, rather than putting extra commits afterward.

To be more specific, other users who have pulled the bad commits will not be able to do a simple "fast forward" update of the branch after you fix it. It should be an easy matter, though, for anyone relatively familiar with git to resolve the differences with a git rebase or whatever they need.

the paul
  • 8,972
  • 1
  • 36
  • 53