1

About 2 weeks ago I released a new version of my software, but I made the mistake to not branch/tag at that time. So, now on my branch there is new code.

I was asked to rebuild the same version released 2 weeks ago with some hotfix so I'd like to check out the code that was there at the time and create a new branch from that.

I did the command 

git checkout 'master@{2019-01-10 08:30:00}'

but I already know it doesn't work: on my system there are files dated on 20-01-2019! What am I doing wrong?

Phate
  • 6,066
  • 15
  • 73
  • 138
  • Why not check out and tag the contemporary commit? – isherwood Jan 24 '19 at 21:52
  • ?Can you give me an example please? – Phate Jan 24 '19 at 21:54
  • `git checkout f87sdf87sdf; git tag "blah"; git push --tags` – isherwood Jan 24 '19 at 21:55
  • Better: https://stackoverflow.com/questions/4404172/how-to-tag-an-older-commit-in-git – isherwood Jan 24 '19 at 21:57
  • 2
    The `ref@{date}` syntax picks a commit based on the reflog. The result is usually (always?) a detached HEAD, and any files updated in the work-tree due to the checkout will have today's timestamp, because Git does not set the time-stamps on work-tree files. – torek Jan 24 '19 at 22:03
  • @torek so you are saying that it worked and the files with today's date are the one that are from that old commit? – Phate Jan 24 '19 at 22:26
  • I expect that's the case. The reflog `@{date}` syntax is a little tricky: without a time, it means "midnight" and if there are many commits in a few days, you might not have the right one, but you should at least be close. – torek Jan 24 '19 at 22:28
  • One statement that seems to be missing from the question is "I do not know for certain what the commit was that was released and there is no way for me to find out." I assume that _must_ be the case otherwise you would just checkout that commit. But I find it strange that it would not be possible for you to find out. – Mort Jan 24 '19 at 23:30

0 Answers0