When darcs expect an option to match a number of patches, it doesn't
return any error if cannot find any matching patches. This is in
contrast for when the option is expected to match a single patch.
Some examples should clarify better than I could.
$ darcs initialize R
$ cd R
$ darcs log --patches xxx ; echo rc=$?
'--patches' is expected to match many patches and does not return an
error when the list of results is empty. On the other hand,
'--from-patch' is expected to match a single patch (as the start of the
range) and it DOES return an error if it does not succeed:
$ darcs log --from-patch xxx ; echo rc=$?
darcs-screened: Couldn't find patch matching "patch-name xxx"
CallStack (from HasCallStack):
error, called at src/Darcs/Patch/Match.hs:654:43 in
The same applies to all commands. For example:
$ darcs rebase suspend --tags xxx ; echo rc=$?
No patches selected!
$ darcs clone --tag xxx . ../S ; echo rc=$?
WARNING: creating a nested repository.
Copying patches, to get lazy repository hit ctrl-C...
Going to specified version...
darcs-screened: Couldn't find a tag matching "tag-name xxx"
CallStack (from HasCallStack):
error, called at src/Darcs/Patch/Match.hs:665:43 in
(please also note that the last case is a bit misleading, as the clone
succeeds, but it behaves as if the '--tag' option wasn't passed).
$ darcs --version
$ darcs --exact-version
darcs compiled on Mar 24 2017, at 22:28:36
[show repo: fixed formatting (boringfile Pref overflowed alignment)
Ben Franksen <email@example.com>**20170323124112
* [Sun, Mar 26, 2017 at 08:23:37AM +0000] Ben Franksen:
>Perhaps the intention here was that the pural indicates "zero or more",
>so zero is an expected result?
Probably yes. The fact is that it is not consistent. For example:
$ darcs diff --from-patch xxx --to-patch yyy
raises an error, while
$ darcs diff --index x-y
doesn't, despite the fact they are conceptually the same case.
Also, given that '-h' is an alias to '--match' instead of '--matches'
(more about this on another mail),
$ darcs log --matches 'hash xxx'
does not croak, while
$ darcs log -h xxx
In general, I think darcs should always return an error code when cannot
found a patch he was asked for, both for consistency and for easing
Better, darcs should return a specific, different from 1, error code for
this (let's say 20), so that for example
$ darcs diff --patch x file
20 if the patch cannot be found
1 if there are differences in the two versions of the file (similarly
to the *nix diff command)
0 if the two versions of the file are the same
 Also, I'm surprised --index doesn't croak about not being fed
 Just for example, as naming convention has often been referred as a
sort of branching, `darcs log -p '<BRANCH>'` could be a quick check for
testing we have the right branch.
Am 01.04.2017 um 18:03 schrieb Gian Piero Carrubba:
> Gian Piero Carrubba <firstname.lastname@example.org> added the comment:
> * [Sun, Mar 26, 2017 at 08:23:37AM +0000] Ben Franksen:
>> Perhaps the intention here was that the pural indicates "zero or more",
>> so zero is an expected result?
> Probably yes. The fact is that it is not consistent. [...]
I agree with all your points. Indeed the way the matching options are
handled is far from optimal wrt consistency. If you are interested in
digging into the sources and cleaning things up, you are welcome (as far
as I am concerned).
The idea of using a dedicated return code for 'no matching patch for
this operation' is nice. I have often complained about the ubiquitous
use of 'fail' everywhere and added a function 'die' to
Darcs.Util.Exception to help fight 'fail' (its is used only in a few
places that I cleaned up some time ago). It would be nice to have
another function there e.g. 'nomatch' that exits with appropriate code.
Perhaps even better would be to define a few specific (non-fatal) darcs
exceptions for early termination of a command. These could be handled
when using darcs as a library. A top-level handler (in darcs/darcs.hs)
could then convert these into exit codes for scripting.