Re: [darcs-users] RFC: safer default for patch editing operations

2020-09-25 Thread Ganesh Sittampalam
On 25/09/2020 13:46, Ben Franksen wrote: > Since 2.16 the --not-in-remote option is supported for all operations > that edit the history: amend, rebase suspend, obliterate, and unrecord. > > Should we make this the default behavior? I'm weakly in favour. > Now, if --not-in-remote becomes the de

Re: [darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread Ben Franksen
Am 25.09.20 um 16:42 schrieb James Cook: > Is hijacking patches a common operation for anyone? The least > surprising behaviour would be to always ask the user what to do if > they haven't explicitly chosen an option on the command line; I'd > certainly prefer that. But I've never needed to hijack

Re: [darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread James Cook
On Fri, 25 Sep 2020 at 10:48, Ben Franksen wrote: > Hi Everyone > > I am thinking about changing the behavior and/or available options for > hijacking patches. > > Context: When working from home I have two identities in my > ~/.darcs/author file: one with my work email address and one with my > p

[darcs-users] RFC: safer default for patch editing operations

2020-09-25 Thread Ben Franksen
Hi Everyone Since 2.16 the --not-in-remote option is supported for all operations that edit the history: amend, rebase suspend, obliterate, and unrecord. Should we make this the default behavior? My rationale is that this is usually what you want. Unless modified with --set-default, the defaultr

[darcs-users] RFC: Hiijacking Patches

2020-09-25 Thread Ben Franksen
Hi Everyone I am thinking about changing the behavior and/or available options for hijacking patches. Context: When working from home I have two identities in my ~/.darcs/author file: one with my work email address and one with my private email address. I want to decide which one to use per repo,