[darcs-users] darcs rebase

Ben Franksen benjamin.franksen at bessy.de
Sat Jun 29 18:53:36 UTC 2013


Ben Franksen wrote:
> Ganesh Sittampalam wrote:
>> On 29/06/2013 15:31, Ben Franksen wrote:
>>> (2) The rebase command does not allow me to 'force-commute' two patches. 
> I 
>>> thought that the idea of rebase was to allow that. I dimly remember that 
> in 
>>> an earlier version 'darcs rebase unsuspend' allowed me to select a 
> suspended 
>>> patch without also selecting the (suspended) patches it depends upon. 
> This 
>>> is currently not possible. (I may well remember this wrongly, in which 
> case 
>>> you can regard this a feature request.)
>> 
>> I'd like to support this, and I think I tried once but the code ended up
>> a mess so I wanted to rethink. In the meantime you can workaround as
>> follows:
>> 
>> - Suppose you want to force commute A and B (i.e. B depends on A)
>> - clone your repository, and in the clone, suspend A and B, then rebase
>> obliterate A, and unsuspend B and deal with the conflicts
>> - in the original repository, obliterate B and suspend A, then pull in
>> the fixed up B, and unsuspend A and deal with the conflicts

Your last bullet point can be simplified: just pull A from the original to 
the clone, and then deal with the conflicts.

However, if your goal is to avoid conflicts in the resulting repo, then the 
simplified variant works only in simple cases like the one discussed here. 
More generally, it works if A is a single patch or if it is a sequence of 
patches that all commute with each other.

If A consists of two or more patches and you have dependencies between them, 
then you must pull them in one go, suspend them all, and then unsuspend them 
one by one, amending each patch with the resolutions that "belong to them". 
(See also below).

>>> The reason I want to do that is that I want to pull a fix from 
> development 
>>> branch to stable branch, but the fix (accidentally) depends on some 
> complex 
>>> development change I made. Of course I expect to get conflicts when I 
>>> finally unsuspend the "complex change" /after/ the "fix" and I am ready 
> to 
>>> resolve them manually. I would even expect having to do some conflict 
>>> resolution when unsuspending just the fix.
>> 
>> Yeah, this definitely makes sense, just needs some work to support
>> nicely. In an ideal world, I think you'd also only have to deal with the
>> conflicts once: whatever you do to resolve B should also imply how to
>> resolve A. That'll be a step further though :-)

Yes, and IMO not very important, contrary to what I said before: ;)

> It would be extremely cool to only have to resolve the conflicts once. If 
> you can manage to implement this, you'd have a happy regular user in me 
;-)

I am no longer quite so sure about that. I just found that in my case I 
*wanted* to do the resolution patch-by-patch, so I can put the necessary 
changes where they belong, so I have a clean history (the practical 
advantage of which being that someone else can pull the patches one-by-one 
and test each one individually).

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachm€nts



More information about the darcs-users mailing list