Re: Darcs equivalent of force-pushing and branching

Am 12.10.21 um 09:56 schrieb Alexis Praga:
> Regarding interactive selection, it looks like the modifications should
> be into applyCmdCommon from Apply.hs (unless I'm mistaken !).

Right.

> However, I'm a bit confused about which patches should be offered for
> selection. My first idea was to narrow it down to only patches with
> conflicts (as the user already made a choice during the first selection phase).

So the first selection phase is about the patches from the bundle 
("theirs", IOW the ones to be applied, which BTW you can already 
pre-select in this way using the --skip-conflicts option).

The second phase would be selecting "our" patches (for removal). As I 
sketched here http://bugs.darcs.net/msg22912, offering only patches that 
are in conflict with those we selected in the first phase does make 
sense as a merge strategy, but I think this should be a different option 
(named "remove-conflicting" in the list I gave). I'd say let's 
concentrate on getting --mirror (aka --remove aka --obliterate) right 
before we move on to other strategies.

Cheers
Ben

> Ben Franksen <[email protected]> writes:
>> Go ahead. Feel free to amend my patch as you see fit (if you prefer to
>> keep it as is and add more patches, at least remove the "WIP"). You
>> could also try to add the option to the 'push' command.
>>
>> BTW, adding interactive selection of the patches to obliterate in the
>> target repo means we have to think about what to do if not all patches
>> are selected. I guess you'll want to fall back to the standard merge for
>> what remains. And if we do that we might also want to drop the
>> restriction I added for simplicity, namely that there must not be any
>> unrecorded changes in the target repo.
>>
>> We should also, perhaps, reconsider the name of the option, which fits
>> only the case when the user selects all patches.
>>
>> Finally, since we now have two patch selection phases we have to choose
>> whether -a/--all affects both phases or only the first. This is similar
>> to 'rebase apply' and 'rebase pull' where the behavior is currently that
>> -a affects only the first phase.
>>
>> Cheers
>> Ben
>> -- 
>> I would rather have questions that cannot be answered, than answers that
>> cannot be questioned.  -- Richard Feynman
>>
>>
>> _______________________________________________
>> darcs-users mailing list
>> [email protected]
>> https://lists.osuosl.org/mailman/listinfo/darcs-users
> 


-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman