For example, I’d like to do the following…
$ git tag -a v1.0 [-d 2012-01-01] -m 'the demo version from January 1, 2011'
… and have the tag reflect the repository for all commits on that date.
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Note that you’re actually asking for something tricky. Suppose that
Brepresents a commit made before the date in question, andArepresents one made after it, and your history looks like this:Where do you want your tag? Probably at that merge commit. It’s already tricky to define. Now imagine the merges are more complex, that some of the commits made before the given date weren’t pushed to the central repo until after, and so on. You can come up with a definition, but it’s not anything simple, and not a concept that’s built into Git in any way.
Of course, if your history is linear, and you’re not worried about when things were published, there’d be an easy-to-find commit, which you could get with:
(There’s also
--after, to find all commits after the given date.)This is a bit beside the point anyway; what you should really aim for with tags is marking version, milestones, stable points, versions that were released or distributed, and so on. Of course it’s best to tag them as they occur, but you may still be able to figure it out about past versions. These are the kinds of tags that will tend to actually be useful.
If you still want to try to make retroactive date-based tags, and your history isn’t simple, Adam’s suggestion is the closest you’re likely to get, but do note the caveats I described in the comments there. Note that for it to really be meaningful, you’d want to know what the central repository had on that date, not your local one. Reflogs aren’t by default enabled in bare repositories, but if you happen to have turned them on there, you could get the commit in question by going to that bare repository and running
git rev-parse master@{2012-01-01}. Otherwise, the next best thing in your local repository would begit tag v1.0 origin/master@{2012-01-01}– giving you the position of your tracking branch on that date.