darcs

Patch 1550 remove the match option hack for clone

Title remove the match option hack for clone
Superseder Nosy List bf
Related Issues
Status needs-screening Assigned To
Milestone

Created on 2017-04-01.14:23:14 by bf, last changed 2017-04-21.07:10:51 by bf.

Files
File name Status Uploaded Type Edit Remove
patch-preview.txt bf, 2017-04-01.14:23:14 text/x-darcs-patch
remove-the-match-option-hack-for-clone.dpatch bf, 2017-04-01.14:23:14 application/x-darcs-patch
unnamed bf, 2017-04-01.14:23:14 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg19412 (view) Author: bf Date: 2017-04-01.14:23:14
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 <ben.franksen@online.de>
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
  --to-whatever.
  Tests have been adapted accordingly.
Attachments
msg19476 (view) Author: bf Date: 2017-04-20.18:32:47
I am of a mind to push this into screened, since there have been no
protests so far. If you think this is a bad idea, speak up!
msg19480 (view) Author: ganesh Date: 2017-04-21.03:50:08
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?
msg19483 (view) Author: bf Date: 2017-04-21.07:10:50
> Ganesh Sittampalam <ganesh@earth.li> 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).

Cheers
Ben
History
Date User Action Args
2017-04-01 14:23:14bfcreate
2017-04-20 18:32:47bfsetmessages: + msg19476
2017-04-21 03:50:08ganeshsetmessages: + msg19480
2017-04-21 07:10:51bfsetmessages: + msg19483