[Bug 5546] New: Optionally "lock" changesets; Make them unstrippable, undeletable.
mercurial-bugs at mercurial-scm.org
mercurial-bugs at mercurial-scm.org
Tue Apr 25 23:31:15 UTC 2017
https://bz.mercurial-scm.org/show_bug.cgi?id=5546
Bug ID: 5546
Summary: Optionally "lock" changesets; Make them unstrippable,
undeletable.
Product: Mercurial
Version: unspecified
Hardware: PC
OS: Windows
Status: UNCONFIRMED
Severity: feature
Priority: wish
Component: Mercurial
Assignee: bugzilla at mercurial-scm.org
Reporter: d.kaden at braemacca.com
CC: mercurial-devel at mercurial-scm.org
I would like a way to "lock" changesets to prevent them from being deleted.
Or, to avoid confusion with other meanings of "lock", I would like to make
changesets unstrippable, or undeletable.
Typically, these would be investigational or trial versions that I do not
intend to push to another repository, ever, but that I want to keep
indefinitely. They might be at the end of a line of changesets that have
already been grafted to another branch, thus appear to be unneeded. I want to
prevent deletion of nodes that appear to be unneeded if they are ancestors of
any "unstrippable" nodes.
For example, if I attempt to strip node 2, but node 100 is a descendant of node
2, and is marked "unstrippable", Mercurial will refuse to delete node 2.
As a suggestion, this might be implemented as a new phase, one step beyond
"secret". Alternatively, it might be implemented as a setting independent of
phase, allowing any secret, draft, or public node to be unstrippable. The
second method is probably better, so that pulling from another repository won't
change a node from "unstrippable" phase to public.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Mercurial-devel
mailing list