[darcs-users] [issue1588] option for darcs pull to just get non-conflicting patches

Ganesh Sittampalam ganesh at earth.li
Sun Sep 6 19:24:47 UTC 2009

On Sun, 6 Sep 2009, Eric Kow wrote:

> Hi Ganesh,
> I'm transferring the discussion for issue1588 to darcs-users :-)
> We'll have to remember to follow up later.
> On Sat, Sep 05, 2009 at 22:45:39 +0000, Ganesh Sittampalam wrote:
>> I'm not actually convinced that what's needed for this bug is the same 
>> as for issue1263; in particular --match is about existing properties of 
>> patches whereas the option to pull would be more about potential 
>> conflicts. It also has to cover conflicting patches and dependencies of 
>> conflicts, whereas a --match option might well not do that.
> Well matchers already deal with dependencies (or rather darcs operations
> that deal with matchers).

OK, I wasn't sure about that, thanks.

> One point is that if we were to implement issue1263, we would either 
> have to disable the conflicted matcher for pull, limit its meaning to 
> refer to a property of the candidate patch wrt the remote repository or 
> enable it but have the matcher also compute conflictedness in the 
> current context.  I thought that from a UI perspective, it would be more 
> consistent to enable the conflicted matcher at all times.

Agreed, we should definitely enable the conflicted matcher at all times 
once it exists, but I also think that what it matches in a given repo 
shouldn't change depending on what command is run, which pushes us into 
the implementation for pull being "property of the candidate patch wrt the 
remote repository".

> At the risk of rambling incoherently: I imagine that making this work
> would be hard because now you can't do matching in a separate pass from
> pulling.  Conflictedness would have to be measured in the context of
> each patch as you go. Yuck.  I wonder how we deal with the touch
> matcher.  For example how does pull --match 'touch foo' interact with
> context where things have renamed foo, or renamed things to foo?

Yes, that too.

So overall I think the conflicted matcher would be independent of the 
option to darcs pull that does know about conflicts that *would* happen 
rather than those that have already happened, and these bugs should stay 



More information about the darcs-users mailing list