The new patch format omits a linefeed before the first "atomic change". This
adds a totally unnecessary special case to patch parsing.

For example:

[repo change - file added
test@example.com**20080518092406] addfile ./foobar
hunk ./foobar 1
+junk test file....

[another test
test@example.com**20080518092520] hunk ./foobar 1
-junk test file....
+sdklfhsldajkdfhjjunk test file....

Should be:

[repo change - file added
test@example.com**20080518092406]
addfile ./foobar
hunk ./foobar 1
+junk test file....

[another test
test@example.com**20080518092520]
hunk ./foobar 1
-junk test file....
+sdklfhsldajkdfhjjunk test file....


"The cat is already out of the bag" so darcs will have to understand it both
ways. Still, I would like to see darcs format new patches consistently from now on.

Ideally darcs repair would quietly correct this.... However, I suspect
corrections would ripple back through the inventories and break repository
history (by cosmetically rewriting patch file hashes).

To clarify, where is the inconsistency?  Between darcs2 and darcs1 (both hashed)
or between hashed and unhashed?

The inconsistency is that the first "atomic change" starts in the middle of the
line, while all other "atomic changes" start at the beginning of the line. This
is relevant to anyone writing a parser for the darcs2 patch format.

This appears to be a side effect of the code that removed curly braces from the
patch format.... It looks like an extra newline was removed, that should have
been left alone.

In darcs2 no patches use curly braces. In darcs1 hashed, curly braces are used
on patches with multiple "atomic changes" but are inconsistently omitted from
patches with only one "atomic change". (See more serious bug #862.)

I don't think this is a new change. I have patches from 2004 (darcs-1) where a
single change (without curly braces) is separated from the closing ] sometimes
with a space and sometimes with a newline. I think the definition simply says
whitespace (don't remember if it's only one or more), and that whitespace is
defined as space, tab or newline.

Is there any technical/tricky impedence that prevents this?

This is just to join the original request: it is so common to review
each other's changesets over email, that this little wart hits the
eyes badly.

If, as Tommy said, """... is separated from the closing ] sometimes
with a space and sometimes with a newline""", I guess it should be
hard starting from now to change that to "always newline".

I know I'd like to give up trying to focus on my possible new job and
learn another bit of Haskell trying to figure it out on my
own instead... but I'll try to resist, waiting for other opinions :)

thanks&bye,
lele.
-- 
nickname: Lele Gaifax    | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas    | comincerò ad aver paura di chi mi copia.
lele@nautilus.homeip.net |                 -- Fortunato Depero, 1929.

> If, as Tommy said, """... is separated from the closing ] sometimes
> with a space and sometimes with a newline""", I guess it should be
> hard starting from now to change that to "always newline".

Err, I meant "it should NOT be hard", sorry.

On Fri, Dec 05, 2008 at 01:01:08PM -0000, Lele Gaifax wrote:
> > If, as Tommy said, """... is separated from the closing ] sometimes
> > with a space and sometimes with a newline""", I guess it should be
> > hard starting from now to change that to "always newline".
> 
> Err, I meant "it should NOT be hard", sorry.

Exactly. The parser that reads patches should accept any
whitespace (tab, newline or space), so when we write patches we
can use whichever we like. I too would like newline, because
it's so much easier to read for humans.

I once tried to fix this, but I think my change overshot (was creating
too much whitespace) and so I gave up.