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

Ben Franksen ben.franksen at online.de
Fri Sep 25 12:46:53 UTC 2020


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 defaultrepo is the one from which you cloned, which
is typically the "upstream" repo (see also the new (in 2.16)
--inherit-defaults option). It makes these operations less "unsafe", as
it means that by default you are offered only patches that are not yet
published i.e. part of "upstream".

I am using quotation marks here because whether the default repo is
considered "upstream" or whether history editing is considered "unsafe"
is a matter of convention. Technically, all repos are created equal and
there is nothing inherently unsafe about editing the history of a public
repo.

Mercurial has at some point introduced so called "phases" to mark
changesets as either "public" or "draft" (or "secret"). This information
is attached to the changeset and also gets transmitted when they are
exchanged between repos. In my experience this is too restricting. There
are situations where I want to edit a patch that has already been pushed
to another repo, and Mercurial makes it very awkward to do so. The
--not-in-remote option is less powerful, but more light-weight and
flexible. Also, whether a project considers its public repo(s) as
"stable" in the sense of "no history editing happens here" is (IMO) a
matter of policy and I want Darcs to be agnostic w.r.t. policy as far as
possible (and practicable), which means it should be easy to switch to a
different policy, in other words, negate the default behavior with an
option or specify a different default by modifying ~/.darcs/defaults.

Now, if --not-in-remote becomes the default, how do we name the option
that negates it? Simply dropping the "not" as in --in-remote is
certainly confusing. OTOH something like --force is too general, it
could mean lots of different things. More specific would be
--also-in-remote or --even-in-remote. Or perhaps we want to invent a
completely new name for the option.

Please chime in if you have any suggestions or comments.

Cheers
Ben



More information about the darcs-users mailing list