I don't even know if this can really be considered a bug.

1. darcs get http://wiki.darcs.net (big history)

2. create a patch (darcs send -O)

3. darcs unpull

4. darcs apply the patch

This takes forever.  If you look at the --debug output, it's trying to read
through every patch in my history.

Note that the missing patch in my case was a tag.
See http://lists.osuosl.org/pipermail/darcs-users/2009-August/021091.html

On Sun, Aug 30, 2009 at 12:27:30 +0000, Eric Kow wrote:
> 3. darcs unpull

darcs unpull the patch *and* things it depends on

The attached script illustrates the problem (it may need some refining for clarity).

This happens in cases where somebody tries to apply a patch without having
pulled from the repo sent from.  The fact that the missing patch is a tag is
important, I think because that's where the bundle gets cut off -- we don't have
a frame of reference that we can use to stop searching through the history.

OK, at first I thought there wasn't much of a solution and that we maybe needed
issue1505 (hashed context files) to fix this, but now I think there may be an
answer: how about doing the equivalent of a darcs show tags first?

Attachments

• issue1590.sh

I confirm this still exists in darcs HEAD (as of June 17th 2010).
I used the command "darcs obliterate -O" to go back earlier in my
history but to be still able to re-apply my latest patch. When doing
"darcs apply", I have the message:
"Merging us 60 done, 288 queued"

I think "darcs obliterate -O" is almost useless while this bug exists.

My problem happens with only obliterating one patch. So I don't see why
this should give a wrong context in the patch bundle.

This seems to be fixed now.