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

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

[Dirk Süsserott]

Hello,

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.

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 imagine to translate "now" to "localtime(time(0))". Would that be good?

Dirk

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

[Jeff King]

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> That being said, with --reset-author I have never needed --date, so I
> don't personally care if it gets done or not.

In short, should I take that the resolution of this issue is "I didn't
know about --reset-author and asking for --date=loose was an X-Y problem"?

I agree with you that we would not want to loosen the specification side
(i.e. "commit --date=" as opposed to the selector side "log --since=")
unless we absolutely have to.

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

[Jeff King]

On Mon, Mar 07, 2011 at 04:20:59PM -0800, Junio C Hamano wrote:

> > That being said, with --reset-author I have never needed --date, so I
> > don't personally care if it gets done or not.
> 
> In short, should I take that the resolution of this issue is "I didn't
> know about --reset-author and asking for --date=loose was an X-Y problem"?
> 
> I agree with you that we would not want to loosen the specification side
> (i.e. "commit --date=" as opposed to the selector side "log --since=")
> unless we absolutely have to.

It is up to Dirk to say whether it solves his particular problem or not.
But thinking on it more, --date=now does encourage a bit of a wrong
workflow. Why would you be resetting the date but _not_ taking
ownership? Maybe a reasonable situation for that exists, but I couldn't
think of one.

-Peff

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

[Andreas Schwab]

Jeff King <peff@peff.net> writes:

> Why would you be resetting the date but _not_ taking ownership? Maybe
> a reasonable situation for that exists, but I couldn't think of one.

If you are already the author it's not so obvious that you have to reset
authorship in order to reset the date.  Also, if you are the author, but
under a different email you may not want to change that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Dirk Süsserott]

Am 08.03.2011 19:51 schrieb Andreas Schwab:
> Jeff King<peff@peff.net>  writes:
>
>> Why would you be resetting the date but _not_ taking ownership? Maybe
>> a reasonable situation for that exists, but I couldn't think of one.
>
> If you are already the author it's not so obvious that you have to reset
> authorship in order to reset the date.  Also, if you are the author, but
> under a different email you may not want to change that.
>
> Andreas.
>

Thank you, Peff and Andreas. Indeed I never tried --reset-author before 
but it works fine for my problem, as the authorship/email didn't change 
between the commits. However, I personally think --date=now should work 
everywhere but if you don't like it I will definitely not insist on it. :-)

In case I _really_ need it, I could use sth. like
--date=$(perl -e 'print localtime').

Dirk