[darcs-devel] option fix for clone command and issue 2447

Ben Franksen ben.franksen at online.de
Sat Jun 13 21:14:18 UTC 2015


Ganesh Sittampalam wrote:
> FYI http://bugs.darcs.net/patch1233 has the history of that comment - it
> was a fixup after the options refactoring.
> 
> I'm afraid I haven't fully understood what's going on here. Personally
> I've never found the range matching commands particularly clear or easy
> to use - it may well make sense to change them.

Hi Ganesh

thanks for your reply. It looks to me as if it would be possible to fix the 
option thing with relatively little effort.

My current concern is to arrive at a (any) workable solution for issue 2447. 
I was searching for a way to "apply" patches in memory in a way that only 
applies the part of the patch that concerns the existence of files, not 
their content. This would be much faster than on-disc application of the 
whole patch sequence and at least solve the problem with 'darcs show files'. 
It looks as if to do this I need to create a new instance of ApplyMonad.

For 'darcs show contents' something similar might work. There we want to 
restrict patch application to a concrete list of files (typically one). The 
problem here is that presence of a 'darcs move' patch might mean we have to 
re-start from the beginning (with the source of the move added to the list 
of files).

Do you think this might work? Is there any prior work I can build on (I 
mean: patch application in memory that ignores some of the information in 
the patches)?

Cheers
Ben

> On 13/06/2015 21:13, Ben Franksen wrote:
>> Replying to myself...
>> 
>> It seems that yes, the way --to-match is handled by clone is correct. And
>> indeed, using code similar to what clone does in order to fix issue 2447
>> seems to work but is of course extremely inefficient if the patch is at
>> the end of a long history.
>> 
>> Is there a better way? Could we, perhaps, tentatively obliterate patches?
>> I guess the typical use cases are for patches near the end of the repo.
>> Any other ideas?
>> 
>> Cheers
>> Ben
>> 
>> Ben Franksen wrote:
>>> Hi Ganesh (and others)
>>>
>>> you wrote this comment in the code of the clone command:
>>>
>>> -- The 'clone' command takes --to-patch and --to-match as arguments,
>>> -- but internally wants to handle them as if they were --patch and
>>> --match -- TODO: remove this when we get rid of directly looking at
>>> [DarcsFlag] -- for this command.
>>>
>>> I am wondering about this. The same file contains this as documentation:
>>>
>>>   , "You can also make a copy of an untagged state using the
>>>   `--to-patch`
>>> or"
>>>   , "`--to-match` options, which exclude patches *after* the first
>>>   matching"
>>>   , "patch.  Because these options treat the set of patches as an
>>>   ordered" , "sequence, you may get different results after reordering
>>>   with `darcs" , "optimize`, so tagging is preferred."
>>>
>>> This suggests to me that --to-match etc *should* give us the documented
>>> behavior. I am wondering how the clone command can work as documented if
>>> it (internally) uses non-range matchers. The procedure used is
>>> Darcs.Repository.Match.getOnePatchset and I wonder: is this really doing
>>> what I think it does (i.e. the equivalent of --to-match etc )?
>>>
>>> The question came up when I looked into issue2447. I tried to find an
>>> existing set of match options that better represents what the users
>>> expect. I found that
>>>
>>>   matchOneContext = mconcat [toMatch, toPatch, toHash, tag, context]
>>>
>>> fits nicely and is already used by the clone command, so wanted to see
>>> if I can steal its patch selection code. So I now wonder if I should use
>>> the same trick as with clone i.e. re-map the match flags and use
>>> Darcs.Repository.Match.getOnePatchset? I see that annotate is the (only)
>>> other command that uses this function. It would help if we knew that
>>> clone and annotate do not suffer from the equivalent of issue2447.
>>>
>>> Assuming getOnePatchset does indeed choose the correct set of patches
>>> (everything up to and including the matching patch), I can try to
>>> re-write it to work correctly with range-matching options, so we can
>>> avoid the ugly re-mapping of match flags.
>>>
>>> Cheers
>>> Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams




More information about the darcs-devel mailing list