Re: [RFD] use approxidate for "git commit --date=xyz"?

[Peter Krefting]

Junio C Hamano:


But why does the workflow need --date=now in the first place?


I tend to do this quite a lot, after fixing up a commit using rebase, 
I notice that the commit date is when I first started fixing the 
issue, even if that was a week or so ago. I then like to reset the 
commit date to reflect when I actually was done with it, and try 
"commit --amend --date=now".


I just haven't been annoyed enough to patch the code to fix it (so the 
git repository at my $dayjob does have a number of commits with the "wrong" 
commit time in it [1]), but I would welcome such an addition.


--
\\// Peter - http://www.softwolves.pp.se/

 [1] The last such is one that took me about a week to implement:
  AuthorDate: 2014-04-15 15:48:38 +0200
  CommitDate: 2014-04-22 09:23:25 +0100
 it'd look better to have the AuthorDate at the 22nd as well, imho.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] use approxidate for "git commit --date=xyz"?

[Jeff King]

On Wed, Apr 30, 2014 at 02:34:59PM -0700, Junio C Hamano wrote:

> Linus Torvalds  writes:
> 
> > I just got a comment saying that
> >
> > git commit --amend --date=now
> >
> > doesn't work. I replied that you can use
> >
> >--date="$(date)"
> 
> Offhand without double-checking the actual codepath I do not have
> objection against approxidate-careful.

This has come up a few times on the list, but nobody ever produced a
patch. To quote myself[1]:

> 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.

I think it would make sense if we followed both of those points.

Should we also loosen $GIT_AUTHOR_DATE? I'd prefer not to, as that is
not typically fed by the users themselves, but rather by scripts, and
being robust there may be more valuable.

> But why does the workflow need --date=now in the first place?
> Wouldn't --reset-author do what you want better?  What is the
> situation where you want to say that this patch has been changed
> significantly enough from the original to label it with the current
> timestamp without taking the authorship?

In some of the instances on the list, the user simply didn't know that
--reset-author would do the trick. And I do think it's slightly
unintuitive.

However, the original rationale for "--date" was to back-date
commits[2], so even though there is an equivalent for "--date=now", it
might be nice to support "--date=2.days.ago".

-Peff

[1] http://article.gmane.org/gmane.comp.version-control.git/168596

[2] http://article.gmane.org/gmane.comp.version-control.git/134406
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] use approxidate for "git commit --date=xyz"?

[Junio C Hamano]

Linus Torvalds  writes:

> I just got a comment saying that
>
> git commit --amend --date=now
>
> doesn't work. I replied that you can use
>
>--date="$(date)"

Offhand without double-checking the actual codepath I do not have
objection against approxidate-careful.

But why does the workflow need --date=now in the first place?
Wouldn't --reset-author do what you want better?  What is the
situation where you want to say that this patch has been changed
significantly enough from the original to label it with the current
timestamp without taking the authorship?

> but I do wonder if we should accept the approxidate format - we do in
> other equivalent places. Hmm?
>
> The code uses fmt_ident(), which uses parse_date(), which in turn uses
> parse_date_basic(). Maybe parse_date() could use
> "approxidate_careful()" instead of "parse_date_basic()"?
>
> Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html