[darcs-devel] [patch1913] get rid of Invert instances for non-prim patch types

[Benjamin Franksen]

>> When/if your rebase refactor gets finished, we may want to add 
>> (redundant) RepoPatch constraints there, so that we cannot abuse
>> them in the way you indicated. This would also require us to
>> implement the check/repair stuff for RebasePatch, see below, so
>> better postpone that until we have got the essentials right.
> 
> Don't Named and PatchInfoAnd satisfy RepoPatch?

No because Named does not have an instance FromPrim.

> It's certainly plausible that they could.

True. But the way I see it this is not the intention of RepoPatch. Yet
another argument against turning it into a constraint synonym: with a
class we can make intention explicit by not defining an instance.

>> It would help a lot if rebase had an explicit command to
>> force-commute suspended patches. Currently the only way to do that
>> is to obliterate one of the patches which means the we must drop
>> /all/ explicit dependencies on that patch, even for any later
>> patches that aren't involved in the force-commute. This is pretty
>> bad because choosing exactly which explicit dependencies are
>> required is not easy. I have hopes that when your refactor of the
>> rebase internals is done we can add such a (sub)command more
>> easily.
> 
> I had been thinking about it as this is something I really want too 
> (hence the email to darcs-users in June). I don't use explicit 
> dependencies much - perhaps I should - but not having to resolve the 
> conflicts twice would make a big difference to usability.

Yup, that too.

>> (BTW you seem to be re-setting the title to "WIP: ...", I guess
>> this is an unintended side-effect of how you use the tracker? I
>> always use my email client for messages, nowadays, since at some
>> point the web-interface stopped formatting the text with line
>> breaks...)
> 
> I've been using my email client almost exclusively too, and I noticed
> it happening yesterday. It's because the patch tracker takes the
> subject of the most recent email as the issue title, and the mail
> with the final bundle had WIP in the subject. In fact immediately
> after I noticed and manually reset it, I think you actually sent an
> email that put the WIP back :-)

Oh. Interesting. I didn't expect that to happen. A nice feature in fact,
if you happen to know about it ;-)