$ darcs send -O/tmp --last 4 http://darcs.net/screened
command line: unrecognized option `--last'
Bad argument: `4 http://darcs.net/screened'
Usage: darcs send [OPTION]... [REPOSITORY]
Prepare a bundle of patches to be applied to some target repository.

See darcs help send for details.

$ darcs help send | grep last
$ echo $?
1

From src/Darcs/UI/Options/Matching.hs:62

> -- | Used by: rebase pull/apply, send, push, pull, apply, fetch
> matchSeveral :: MatchOption
> matchSeveral = matches <> patches <> tags <> hashes

I'm sure there a reason why these commands (as opposed to, e.g., log) 
cannot mix the aforementioned options with last, but I failed to find an 
explanation in the documentation (mostly the commit messages), so I'm 
keeping this bug open for documenting it.

Allowing "firstMatcher"s like --last for these commands is possible but 
not quite as easy to implement as one might think.

Consider this scenario:

remote = A;B
local = A;C;D;B

What does it mean to `darcs send --last=2` here? The only consistent 
way to interpret this (see e.g. how it works with the log command) is 
that it means "limit selection to d and b", and thus to d only, since b 
is already in remote.

But what if d depends on c? Then we cannot send d. The way this would 
work is that we first determine the eligible patches "C;D" (using 
`findCommon local remote`), then remove (commute out, towards the end) 
from that sequence everything that is not in the last N patches of 
local i.e. "D;B" in this case, dragging along everything that depends 
on those patches. It would cause the least confusion for users if we 
reported any reverse dependencies that we drop in this way, which 
requires a second pass over the dropped patches. Afterwards we would 
present what remains for interactive selection.

Sorry for mixing upper and lower case for the patch names, I hope it 
is still clear what I meant to say.

Thank you, Ben. What I don't understand is how is --last different from 
other selectors (e.g.: --patches). Let me explain with an example:

darcs ini R
darcs ini S
touch R/file
darcs record -lam A --repo R
echo foobar > R/file
darcs record -lam B --repo R

In this context,

darcs push -p B S --repo R

and

darcs push --last 1 S --repo R

are equivalent, but only the first is implemented (and pulls in the 
dependencies).

So I guess my question can be read as: are there cases in which the use 
of --last cannot be modeled via other selectors? In other words: is 
there an implicit limitation with --last or is it just a lack of 
implementation?

If the latter, please consider this ticket as a request for feature.

Thank you,
Gian Piero.

> What I don't understand is how is --last different from 
> other selectors (e.g.: --patches).

Implementation issues aside, the fundamental difference is that --
patches is independent of the order of patches, whereas --last is 
not.

For commands that transfer patches, we first need to find out which 
patches are common and which are uncommon (only in our repo, only in 
the other repo), before we invoke patch selection. But in general 
this requires changing the order: we need to commute common patches 
so that they come before uncommon ones.

Since the order is irrelevant for --patches, we can first find the 
uncommon patches (ours for push and send, theirs for pull and apply) 
and then select according to --patches afterwards. This does not work 
with --last. Furthermore, selecting according to --last before taking 
the difference is not possible, because we can only compute the 
difference between sequences with the same starting context. (Context 
means: the set of preceding patches; for two complete repos there is 
always a common context, namely the empty one with no patches).

As I wrote before, supporting --last is possible nevertheless, but 
not trivial. Basically, what we need to is first convert --last into 
some order-independent criterion and then apply that criterion after 
taking the difference.

I wrote that --last depends on the ording of patches, which should be 
obvious. The same is true for --from-patch/match and --to-patch/match 
as well as --index=FROM-TO. These options select a /range/ of patches 
i.e. from the complete sequence of patches in a repo they (pre-)select 
a contiguous subsequence; in case of --from/--to delimited by the 
/latest/ patch (i.e. the first we encounter when we go backwards in 
the history starting with the head) that satisfies the given 
condition.

What I said about --last can be generalized to all these "range 
matchers": to support them for commands that transfer patches, we 
first need to convert them to an order-independent criterion, then 
calculate the difference between the two repos, then apply that 
criterion to "ours-only" or "theirs-only", depending on the direction 
of transfer.

A suitable order-independent criterion could be represented as 
something like --hash, but with a set/list of hashes as argument.