Check this one out.  I was trying to apply patch345 to my local copy of
unstable [context attached].

It has one patch more than HEAD does (kind of buried).

Note that at the time of this bug, HEAD was missing the 2.4.98.2 tag.

% darcs apply -i
~/Downloads/accept-issue1898_-set_default-notification-system_.dpatch 
darcs: bug at src/Darcs/Patch/Depends.hs:123 compiled Aug 10 2010 22:03:05
tag
Mon Jul 26 19:49:46 BST 2010  Reinier Lamers <tux_rocker@reinier.de>
  tagged 2.4.98.2
is not in the patchset in splitOnTag.
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.

Oh! Also, unpulling the common patch (the issue1898 one), so just having
plain old HEAD also makes it blow up.

Looks like we need another test case!

Attachments

• head-plus-one-context

Note that this appears to be just a more-scary-than-necessary error
message and not Darcs actually doing something wrong. The patch was just
against a context we don't have.  But I guess we may have to look out
for the role that tags play in these...

Note also that you could argue this isn't really a regression because 
Darcs 2.4 just prints a bug in get extra:

darcs-2.4.4: bug in get_extra commuting patches:
First patch is:
Thu Jun 24 19:38:11 BST 2010  Alexey Levan <exlevan@gmail.com>
  * Implement darcs optimize --http
Second patch is:
Wed Aug  4 20:57:38 BST 2010  Petr Rockai <me@mornfall.net>
  * Rename findCommonAndUncommon to findUncommon (it does not find common).

So we're not doing any worse than before! Ah, but to have Petr's nice
new friendly output...

Hi,

Eric Kow <bugs@darcs.net> writes:
> Note that this appears to be just a more-scary-than-necessary error
> message and not Darcs actually doing something wrong. The patch was just
> against a context we don't have.  But I guess we may have to look out
> for the role that tags play in these...
that's easy: with_partial_intersection looks for a common optimised tag,
and findCommonWithThem uses that for improved speed... It also seems
that with_partial_intersection is buggy for this case (it errors out
calling splitOnTag that does not exist). I'll look into that.

Yours,
   Petr.

According to msg12182 (kowey) this is not a regression, so I am bumping 
away from current already-quite-late 2.5.

It's not a regression since 2.5, so bumping to 2.10.

The following patch sent by Owen Stephens <darcs@owenstephens.co.uk> updated issue issue1921 with
status=has-patch

* Resolve issue1921: return Nothing in splitOnTag if the tag isn't in the patchset 
Ignore-this: 9a4962f7336228273ce40f7a50c3172c

The following patch sent by Owen Stephens <darcs@owenstephens.co.uk> updated issue issue1921 with
status=resolved;resolvedin=2.10.0 HEAD

* Resolve issue1921: return Nothing in splitOnTag if the tag isn't in the patchset 
Ignore-this: 9a4962f7336228273ce40f7a50c3172c