[PATCH 3 of 3] histedit: revive commits on demand
pierre-yves.david at ens-lyon.org
Mon Mar 27 03:17:59 EDT 2017
On 03/26/2017 08:41 PM, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu <quark at fb.com>
> # Date 1490552007 25200
> # Sun Mar 26 11:13:27 2017 -0700
> # Node ID b6766d75404fb8c5d26af016caa76f44b47ce156
> # Parent 336512ee2f947f07149e399a84927f9d820d2b62
> # Available At https://bitbucket.org/quark-zju/hg-draft
> # hg pull https://bitbucket.org/quark-zju/hg-draft -r b6766d75404f
> histedit: revive commits on demand
> This is to address the "histedit --abort" issue mentioned in .
There are still issues with that approach. For example in this
1) Alice send changesets to Bob,
2) Bob try to histedit something in the stack, this fails
3) Bob --abort the histedit
4) Bob tell Alice to perform the operation herself since she know the
code better and can resolve the conflict
5) Alice histedit with success
If step (3) created markers for the histedit partial result, these
markers will apply to the result of (5) and create confusion/change
"loss" when the two states are gathered.
This is a non-trivial question and there is good reason why rebase and
histedit do not use obsolescence marker to restore the repository to its
note: this is a case were a local-light-weight "archiving" mechanism
could be handy.
> This solution is safer than what  proposed because it does not use unsafe
> history writing ("strip"). The "strip" has caused several repo corruptions
> in production.
I'm sure upstream would be happy to have some bug report about this and
maybe some investigation about this corruption. Strip corrupting
repository would happily rank a "critical".
> It's similar to what "hg touch" in mutable-history does , without using
> random number. So it could be more reliably tested.
The reason why 'touch' use random number is to ensure operation in one
repository will not -unexpectedly- affect the one in another repo (kind
of like here). We could use sometimes else than random but it cannot be
a simple sequential number.
Note that using random will not solve the issue here since (5) does not
even know yet that the markers in (3) exists.
> Note that if we have obsolete marker versions, and obsoleted revisions are
> revived automatically, as I proposed in , the "revive" hack will be
> longer be necessary.
Please see my (fresh) reply to that other series.
More information about the Mercurial-devel