This is not for screened yet as it introduces incompatibility in the UI and
thus needs discussion and/or approval.
1 patch for repository http://darcs.net/screened:patch 9d5fef08e395ad9b9330cd78eee015cac65f47f9
Author: Ben Franksen <firstname.lastname@example.org>
Date: Sat Apr 1 11:48:55 CEST 2017
* remove the match option hack for clone
Since ancient times the clone command had --to-patch, --to-match, etc but
actually treated them as --patch, --match etc. This patch fixes that: clone
now takes the correct options --match, --patch etc. and no longer supports
Tests have been adapted accordingly.
The --to-XXX and --XXX options always confuse me. My vague intuition is
that --XXX will select a particular patch, and often implicitly its
dependencies depending on the command, but nothing else. --to-XXX will
select a patch, and every patch currently before it in the repository.
Is that intuition right in general, and is that the end result of your
changes to clone?
> Ganesh Sittampalam <email@example.com> added the comment:
> The --to-XXX and --XXX options always confuse me.
You are not alone ;-)
> My vague intuition is
> that --XXX will select a particular patch, and often implicitly its
> dependencies depending on the command, but nothing else. --to-XXX will
> select a patch, and every patch currently before it in the repository.
This is how I always understood it, too. However my understanding is no
less based on intuition as yours (and perhaps, long ago, reading some
documentation). The code that implements the matching is, unfortunately,
rather mysterious to me. (The most mysterious aspect of the patch
matching is what happens when more than one of these matching options
are supplied. I remember that I was regularly surprised that the actual
behavior did not match my intuition when I tried that; I guess I stopped
trying at some point...)
> Is that intuition right in general, and is that the end result of your
> changes to clone?
I think so. The precise end result depends, of course, on whether our
intuitions about how these options are handled is correct. The only
thing I can claim with confidence is that:
Previously, for the clone command, --xxx was not supported, but --to-xxx
was not, and then --to-xxx was silently converted to --xxx.
With my patch, clone directly accepts --xxx and no longer --to-xxx and
there is no longer any conversion happening between these.
So with this patch, usage of clone --to-xxx must be converted to clone
--xxx and should then behave exactly the same as before. This is what I
have done in the test scripts. On my machine the tests pass.
BTW, systematic tests might be a way to specify our expectations about
what matching options do. We could then see how well our intuition
matches the actual behavior (pun intended).