1. A concise subject that expresses the issue:

Got:
darcs.exe: bug at src\Darcs\Patch\Depends.hs:187 compiled Mar 14 2011
23:18:13
Impossible case at src\Darcs\Patch\Depends.hs:187 compiled Mar 14 2011
23:18:13
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.

when obliterate with a subset of patches selected.


2. The exact Darcs version (darcs –exact-version)

Downloaded from: http://darcs.net/binaries/windows/darcs-2.5.2-win1.zip
darcs --exact-version
darcs compiled on Mar 14 2011, at 23:17:58

Context:

[TAG 2.5.2
Ganesh Sittampalam <ganesh@earth.li>**20110313223504
 Ignore-this: f3f57f3eacb2fdd4cdafc581c05058e3
]

Compiled with:

HTTP-4000.0.9
array-0.3.0.1
base-4.2.0.2
bytestring-0.9.1.7
containers-0.3.0.0
directory-1.0.1.1
extensible-exceptions-0.1.1.1
filepath-1.1.0.4
hashed-storage-0.5.5
haskeline-0.6.3.2
html-1.0.1.2
mtl-1.1.0.2
network-2.2.1.7
old-time-1.0.0.5
parsec-2.1.0.1
process-1.0.1.3
random-1.0.0.2
regex-compat-0.93.1
regex-posix-0.94.4
tar-0.3.1.0
text-0.11.0.5
unix-compat-0.2.1.1
zlib-0.5.2.0


Darcs 2.8.1(http://darcs.net/binaries/windows/darcs-2.8.1-win1.msi) has the
similar report:
darcs.exe: bug at src\Darcs\Patch\Depends.hs:225 compiled Jul  9 2012
01:48:26
Impossible case at src\Darcs\Patch\Depends.hs:225 compiled Jul  9 2012
01:48:26
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.

darcs --exact-version
darcs compiled on Jul  9 2012, at 01:48:23

Context:

[TAG 2.8.1
Ganesh Sittampalam <ganesh@earth.li>**20120514063340
 Ignore-this: fbc024be64f47a743c1336c374f9bb14
]

Compiled with:

HTTP-4000.2.3
array-0.4.0.0
base-4.5.0.0
bytestring-0.9.2.1
containers-0.4.2.1
directory-1.1.0.2
extensible-exceptions-0.1.1.4
filepath-1.3.0.0
hashed-storage-0.5.9
haskeline-0.6.4.7
html-1.0.1.2
mtl-2.1.1
network-2.3.0.13
old-time-1.1.0.0
parsec-3.1.2
process-1.1.0.1
random-1.0.1.1
regex-compat-0.95.1
regex-posix-0.95.1
tar-0.3.2.0
text-0.11.2.0
unix-compat-0.3.0.1
vector-0.9.1
zlib-0.5.3.3


3. Platform information (what OS, usually)

Windows XP SP3


4. Simple reproduction steps (ideally, a block of commands that we can copy
and paste into a terminal)

mkdir obliterate
cd obliterate

darcs initialize --repodir single-patch
cd single-patch

mkdir bash
echo 12 > bash/git-completion.bash
darcs add bash/git-completion.bash
darcs record -a -q -m git

echo 26 > bash/darcs_completion
darcs add bash/darcs_completion
darcs record -a -q -m darcs

cd ..


darcs initialize --repodir duplicate-patch
cd duplicate-patch
darcs pull ../single-patch --matches "touch ^\./bash$" -a -q
echo y | darcs unrecord -a
echo yn | darcs record -m "adddir-bash" -q
darcs record -m "addfile-git" -a -q
darcs pull ../single-patch -a -q

cd ..


darcs get duplicate-patch BUGS -q
cd BUGS
echo ny | darcs obliterate --patches add
echo ny | darcs obliterate --matches "name add"
echo ny | darcs obliterate --matches "exact adddir-bash"


Note: the last three commands will produce the same report.
The resemblance is that they both select the subset("adddir-bash" and
"addfile-git") of patches.


5. A Darcs repository URL, and or if you have a broken repository, download
links for tarballs or zip files.

Unnecessary. The above commands can build the repository from scratch.


6. The scenario.

I want to split the "single-patch" repository containing code snippets and
configuration files when it grows large.
Some files(git-completion.bash, darcs_completion) in the same
directory(./bash) should live in different repositories.
The addition of the old files(git-completion.bash) and the addition of
their directory(./bash) are recorded in one single patch(git), and the new
patch (darcs) depends on both "adddir" and "addfile".
Then I decide to amend the "git" patch, split it into "adddir-bash" and
"addfile-git".

The mend has be done in the above example, leaving a duplicate patch, and I
could get two new repositories:

darcs initialize --repodir git
darcs pull       --repodir git    duplicate-patch -a -q -p addfile-git
darcs initialize --repodir darcs
darcs pull       --repodir darcs  duplicate-patch -a -q -p darcs

containing the changes which I want exactly:

darcs changes    --repodir git   -v --reverse | grep ^[[:space:]]
#  * adddir-bash
#    adddir ./bash
#  * addfile-git
#    addfile ./bash/git-completion.bash
#    hunk ./bash/git-completion.bash 1
#    +12
darcs changes    --repodir darcs -v --reverse | grep ^[[:space:]]
#  * adddir-bash
#    adddir ./bash
#  * darcs
#    addfile ./bash/darcs_completion
#    hunk ./bash/darcs_completion 1
#    +26

There is no problem if I only obliterate the "git" patch in the
"duplicate-patch" repository.
For curious, I obliterate both the "adddir-bash" and the "addfile-git"
patches:

darcs get duplicate-patch back -q
darcs obliterate --repodir back -p add -a

and test whether it is identical to the original repository:

darcs push --repodir back single-patch
# No recorded local changes to push!
darcs pull --repodir back single-patch
# No remote changes to pull in!
darcs push --repodir single-patch back
# No recorded local changes to push!
darcs pull --repodir single-patch back
# No remote changes to pull in!

Finally, the problem occurs when I obliterate the "adddir-bash" patch
ONLY...

I also have tested: without patch selecting option(--patches, --matches,
etc.), all the possible permutation of interactive answers('y' or 'n') will
work correctly, i.e., I can't obliterate the "adddir-bash" patch only.
The problem occurs only when a subset of patches are selected.

However, this bug is not a big problem to me, currently.
The ability of manipulating the history very easily and flexibly is the
most attractive feature to me.
In particular, obliterating a public patch in Git is a very costly
operation and is much cheaper in Darcs.
I personally wish leaving this bug alone if the bugfix would hurt this
ability...

Attachments

• unnamed

Hi ownwaterloo,

Thanks for this report!

This is a bit of a tricky one, but it looks like some sort of bad
interaction between dependencies, duplicate patches and patch selection.
It is an example of it being possible to persuade darcs to present a
patch for obliterating that shouldn't be offered, since it has dependencies.

I've split your example down into its key components:

    darcs init --repo single-patch
    darcs init --repo duplicate-patch
    
    cd single-patch
    
    mkdir dir
    touch dir/file1
    darcs record -alm 'dir and file1'
    
    touch dir/file2
    darcs record -alm 'addfile file2'
    
    cd ../duplicate-patch
    
    # Split the dir/file patch into the dir add, and then the file add.
    darcs pull -a ../single-patch -p 'dir and file'
    darcs unrecord -a
    
    # Only record 'adddir ./dir'
    echo yny | darcs record -m 'adddir dir' 
    # Now record the addfile in a separate patch.
    darcs record -am 'addfile file1'
    
    # Pull in the other patches we don't have (which will include the
original 
    # "add dir/file1" patch again since we've amended it to no longer
exist, and
    # the "addfile file2" patch)
    darcs pull -a ../single-patch
    
    # Attempt to obliterate 'addir dir' (but not 'addfile file1'). This
seems to be
    # a problem with the patch selection, since without -p, we aren't
able to
    # obliterate 'adddir dir', if we say no to 'addfile file1' (which is
    # sensible!).
    echo nyy | darcs obliterate -p 'adddir dir'

Which I've just sent as a failing test.

BTW, the way to do this (in HEAD, or likely the next release) would be
to rebase the patches that depend on git, and then directly amend the
original git patch

Cheers,
Owen.