Re: Q about the date format in "git commit --date=..." and such
On Sun, Mar 06, 2011 at 05:07:52PM +0100, Dirk Süsserott wrote:
Show 5 quoted lines
> I frequently change a file in my repo and commit it with
> "git commit -a -C deadbeef", i.e. using an older commit message. The
> "-C" switch also re-uses the author timestamp of the given SHA1, which
> is not what I want. So I tried the "--date=..." switch in addition,
> which works fine.
I also do something like this; I have a repository which gets a weekly update, and I tend to reuse last week's commit message as a template with "git commit -c HEAD --reset-author".
Note that it will _also_ reset the author to you if you were not the original author. But that is probably what you want if you are resetting the timestamp; it is semantically "take ownership of this commit".
> Instead of giving an exact timestamp (like "--date='06.03.2011 16:50'")
> I'd prefer to just say "--date=now". Is that somehow possible? If not:
> would the community appreciate it, if I would try to implement this?
I mentioned --reset-author above, which I think solves your problem. As far as --date=now goes, it doesn't sound like a terrible idea. But there is some question of how far we should take it. We basically have two date-parsing interfaces: parse_date and approxidate.
The former is reasonably strict and accepts what you showed above. We use it for "commit --date=" as well as parsing $GIT_AUTHOR_DATE.
Approxidate, on the other hand, will try to turn any nonsense into a date. So you can say "3 weeks ago" or "tea.time.on.january.1.2011", or even "bogus" (the last of which turns into "now"). So it's flexible, but it may not do what you want. We use this for "log --since", "branch@{date}", and other places.
I think the original rationale was that it's OK for us to allow some sloppiness when _viewing_ commits, since you will generally notice the problem. But when making commits, it's better to be careful, since you may be setting the sha1 in stone.
These days we have two tools that could help:
1. approxidate_careful will do a regular approxidate, but keep track
of whether we found anything even remotely useful. That doesn't
mean you can't still get unexpected results, but at least some
truly useless cases return errors. 2. For commits with a different author and committer, we mention the
author name in the post-commit summary. We could do the same with a
timestamp that was given (i.e., mentioning it in a standard format)
to give the user another opportunity to double-check what we
parsed.That being said, with --reset-author I have never needed --date, so I don't personally care if it gets done or not.
-Peff
