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

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

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

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 c

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

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

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

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