Re: Q about the date format in "git commit --date=..." and such

[Jeff King <peff@peff.net>]

On Sun, Mar 06, 2011 at 05:07:52PM +0100, Dirk Süsserott wrote:

> 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