Just doing a bit of archaeology:
In this patch, I introduced canonizeFL in substantially its current form, from abstracting
this code, and added that comment about issue525 which was presumably discovered from
running the test suite.
patch de7aa3bf018e75e74efee23f98715ab98012c87e
Author: Ganesh Sittampalam <ganesh@earth.li>
Date: Sat Sep 19 01:40:11 GMT Summer Time 2009
* add canonization function for FL Prim
hunk ./src/Darcs/Commands/AmendRecord.lhs 192
- in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ concatFL $ mapFL_FL canonize
- $ sort_coalesceFL $ concatFL $ mapFL_FL canonize $ oldchs +>+ chs
+ in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ canonizeFL
+ $ oldchs +>+ chs
The repeated calls were introduced by David here:
patch 7068e05a83ff602205087495c03ac61e70a98ad2
Author: David Roundy <droundy@darcs.net>
Date: Sat Nov 15 21:19:25 GMT Standard Time 2008
* resolve issue525: canonize output of sort_coalesceFL in AmendRecord.
hunk ./src/Darcs/Commands/AmendRecord.lhs 193
- in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ sort_coalesceFL $
- concatFL $
- mapFL_FL canonize $ oldchs +>+ chs
+ in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ concatFL $ mapFL_FL canonize
+ $ sort_coalesceFL $ concatFL $ mapFL_FL canonize $ oldchs +>+ chs
So the original code before the issue525 fix was "canonize then coalesce". That fix then
made it "canonize then coalesce then canonize". And now you are saying that actually "coalesce then canonize" is enough.
So your change seems plausible if the tests pass, and it also doesn't seem that dangerous:
I think in the worst case we'll get some ugly diffs again, rather than producing corrupt
repositories or something like that.
|