[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