Sometimes patches with one "atomic change" have curly braces and sometimes they
don't. Specificaly, patches imported with 'darcs get --hashed' retain curly
braces, while patches newly created in the hashed repository are not represented
with curly braces.

See the following example. The first two patches were imported with 'darcs get
--hashed', while the second two patches were created directly in the hashed
repository.

[test setup
test@example.com**20080518153437] {
addfile ./baz
hunk ./baz 1
+test setup again
}

[patch format test
test@example.com**20080518153518] {
hunk ./baz 2
+darcs1 test one hunk
+
}

[local one hunk
test@example.com**20080518173216] hunk ./baz 3
+
+one hunk locally recorded in darcs2

[two hunk local patch
test@example.com**20080518173647] {
hunk ./baz 1
-test setup again
+test setup
hunk ./baz 4
-one hunk locally recorded in darcs2
+two hunk locally recorded in darcs2
}

Darcs 2.0.0 stable release binary for MacOS X. Patches were listed with 'darcs
send -o'.

Jason: any chance this could be serious?

Ok, I'm going to escalate because I can't tell if this is worrisome or not, and
I'd rather be safe than sorry.  David: is there any need to be worried about
this bug?

Do you consider this a bug? If so, why?

David

I guess the potential cause for concern was something about hashes being
different for otherwise the same patch created under the different circumstances
(sort of the opposite problem of a collision).  It didn't seem like we really
relied on this for anything in particular, but thought it was worth checking :-)

Otherwise, I think why Ben considers it to be a bug is because it makes it
harder for outside tools be parsing darcs patch files, definitely a lower
priority than the above.