On 5/22/07, Adam Langley wrote:

On 5/22/07, Ross Paterson wrote:

...

nearest needs Num, but the other two shouldn't.

That's a great point, I hadn't thought about that. I don't know if people usually send a correction patch, or remake the patch but I've done the former:

I can't speak for the protocol of this libraries list, but in darcs-devel people usually use 'amend-record' when the changes are small (like correcting a typo). Jason

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (cc'ing darcs-users as this is really a darcs issue) Isaac Dupree wrote:

Jason Dagit wrote:

...

On 5/22/07, Adam Langley wrote:

...

...

nearest needs Num, but the other two shouldn't. That's a great point, I hadn't thought about that. I don't know if

On 5/22/07, Ross Paterson wrote: people usually send a correction patch, or remake the patch but I've done the former: I can't speak for the protocol of this libraries list, but in darcs-devel people usually use 'amend-record' when the changes are small (like correcting a typo).

I prefer making another patch and sending the two patches together, as per the darcs manual http://www.darcs.net/manual/node7.html#SECTION00791000000000000000 in case someone else has already applied the first patch, it makes darcs work better. (the changelog-spamming effect is unfortunate

hmm, would it make any sense for an amended patch to list the identities/hashes of the patches that are obsoleted by it, so that this effect isn't such a problem? (Then there would be a functional reason to use amend-record, so I could complain that there doesn't seem to be a way to remove modifications from a patch using amend-record, just to add them) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWLDLHgcxvIWYTTURArouAKC7jDqiNzL6/K2rvphiA6AiFnEf6wCg1J0+ F86+1fkAxTinzsHBlpNm0TE= =GH0o -----END PGP SIGNATURE-----

"Adam Langley" wrote:

...

That's a great point, I hadn't thought about that. I don't know if people usually send a correction patch, or remake the patch but I've done the former:

In general, the rule would be that a patch published only by email can be amended at low cost, since very few people apply such patches directly to their own repositories. Once a patch has been committed to the main on-line repository however, a large number of people are likely to have pulled it, so amending is no longer suitable, and recording a second patch is preferable. Regards, Malcolm