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 torva...@linux-foundation.org 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 torva...@linux-foundation.org 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