Created on 2023-01-30.17:45:18 by gpiero, last changed 2023-05-29.14:28:15 by bf.
$ 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 $?
> -- | 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
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
darcs push --last 1 S --repo R
are equivalent, but only the first is implemented (and pulls in the
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
If the latter, please consider this ticket as a request for feature.
> 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
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
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
A suitable order-independent criterion could be represented as
something like --hash, but with a set/list of hashes as argument.
|2023-02-07 16:48:06||gpiero||set||title: send does not accept --last option -> some commands (send, push, pull, ...) do not accept the --last option|
|2023-03-17 05:57:37||bf||set||priority: feature|