In the test for issue2208, inserting 'darcs show index' between the
first record and the change to the file leads to a crash of darcs replace:
| darcs replace bar foo testing | not grep Skipping
| + darcs replace bar foo testing
| + not grep Skipping
| + grep Skipping
| darcs: There was an attempt to write an invalid pending! user error
(replace patch to ./testing couldn't apply.)
| If possible, please send the contents of _darcs/patches/pending_buggy
| along with a bug report.
| CallStack (from HasCallStack):
| error, called at src/Darcs/Util/Printer.hs:145:14 in
darcs-2.14.0-inplace:Darcs.Util.Printer
The crash happens in addToPending, where we call readPendingAndWorking
and get a wrong result for the difference between pending and working.
This isn't too astonishing since we pass it a hard-coded UseIndex
instead of the value that reflects the command option (--ignore-times).
Indeed, the problem goes away if we pass IgnoreIndex; or if we pass the
command option to addToPending (since the test suite sets --ignore-times
as default for all commands).
However, I think there is still something not quite right here. How can
the execution of 'darcs show index' lead to 'darcs replace' seeing a
different working tree?? Apparently, 'darcs show index' actually
modifies the index. I have tried to find out how this is possible but I
have a hard time to reason about the index with its strange API. For
instance it looks as if one has to call updateIndex to even get a useful
result (i.e. a tree) from the index. WTF?
Also, in order for the crash to happen, doReplace must have successfully
applied the replace patch to the working tree, otherwise the replace
command would have complained, suggesting you use --force. This means
that the call to readUnrecorded in the replace command returned the
correct working tree, even though readUnrecorded unconditionally uses
the index, too!
This is all pretty mysterious to me.
|
