twb and I were both expecting to find a --date flag on the record command, which
would be used to forge a different date in the unfortunate event that one has to
recreate some patches. In my current broken-repo situation, I think I can get
away with only rerecording today's patches, so I do not need a workaround (this
time). 

I'm not aware of any uses for the patch date inside darcs, so I would guess that
it would be harmless to let the user supply a wrong one.

The desperate admin who is recreating patches may also need to spoof the
username sometimes, but I think that's already trivial so it doesn't need a flag.

On Mon, Dec 22, 2008 at 07:13:47 -0000, Drew Perttula wrote:
> twb and I were both expecting to find a --date flag on the record command, which
> would be used to forge a different date in the unfortunate event that one has to
> recreate some patches. In my current broken-repo situation, I think I can get
> away with only rerecording today's patches, so I do not need a workaround (this
> time). 

Try darcs record --pipe

Ah, that does work. I found two usability bugs in record:

A. darcs prints some inappropriate progress info right after asking for 
the log:

1 % darcs record --pipe
2 What is the date? 2008-12-08T14:00:00
3 Who is the author? drew
4 addfile ./newfile
5 Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
6 What is the patch name? test2
7 What is the log?
8 Reading pristine 0
9 Finished recording patch 'test2'

Line 8 appears right after line 7, and then the cursor goes to the 
beginning of line 8. It's not obvious at all that you're supposed to 
ignore line 8, type as much as you want, and then send an EOF.

B. Date validation is deferred until line 8:

% darcs record --pipe
What is the date? today
Who is the author? drew
addfile ./newfile
Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
What is the patch name? t
What is the log?
darcs: bad date: today - (line 1, column 2):
unexpected "o"

I would expect a hint on the first line, such as (formats include 
ISO8601). Then I would expect a bad date to cause darcs to either abort 
immediately or ask the question again in a loop.

On Mon, Dec 22, 2008 at 11:12:52 -0800, Drew Perttula wrote:
> Ah, that does work. I found two usability bugs in record:

Thanks!  Note that darcs record --pipe is only meant to be used by
automated tools and not people.  If you feel these are still bugs,
please file them separately (sorry for the random burst of bureaucracy,
just trying to keep things trackable)

> A. darcs prints some inappropriate progress info right after asking for  
> the log:

Darcs hackers: it sounds like the fix here would be to disable progress
reporting when using --pipe

> B. Date validation is deferred until line 8:

> I would expect a hint on the first line, such as (formats include  
> ISO8601). Then I would expect a bad date to cause darcs to either abort  
> immediately or ask the question again in a loop.

Note that changing the UI here *might* be undesirable because of tools that
depend on recard --pipe

I needed this functionality in a hurry, so I made this patch.

Note that it just stuffs the value of $DARCS_DATE directly into the
patch -- even if its not a valid date!

I'm sending it here so that I can obliterate it from my repo, while
keeping it around for next time :-)

Sat Apr 18 13:27:57 EST 2009  Trent W. Buck <trentbuck@gmail.com>
  * DRAFT: resolve issue 1276: simple date spoofing.

Attachments

• draft_-resolve-issue-1276_-simple-date-spoofing_.dpatch
• unnamed

Hi Drew,

Retitling.  I'm still against adding a --date flag to record, mostly out of
general knee-jerk resistance to adding new flags.

I'm going to set a wont-fix on some issues you pointed out (although thanks for
them).

I'll bet we can throw in a withoutProgress when we see the Pipe flag for (A) and
make make get_date do a seq somewhere so we get the parse error early and (B)
somehow trigger the date parser as early as possible, but I doubt this will be
very beneficial.

Patches are welcome, of course :-)