Augie Fackler a écrit :
On Fri, Apr 07, 2017 at 12:20:44PM +0200, Pierre-Yves David wrote:
On 04/06/2017 02:46 AM, Jun Wu wrote:
obsstore-based hidden is broken by design, since it cannot unhide commits:
$ hg export . > patch.txt
$ hg prune . # could also be done by pulling obsmarkers from a remote
# peer, or it could be amend / metaedit etc.
$ hg import --exact --bypass patch.txt # cannot really import the patch
The case you describe above work as intended.
I know it's the original intent, but I'm not sure that the original intent is
actually a desirable set of outcomes. I've actually tripped over this usability
wart a decent number of times, usually some variation on this theme:
hg pull marmoute-wip -r some-feature
hg co some-feature
hg rebase -d @
<poke a bit>
hg strip 'ancestors(some-feature) and not ancestors(@)'
<time passes>
hg pull marmoute-wip -r some-feature # which has not moved since the last time
I pulled
<it appears nothing happens>
This briefly confuses *me* when I trip over it, and I've helped work out some of the
design of the feature, which strongly suggests to me that the "is listed as a
precursor in an obsmarker means its always hidden" behavior is suboptimal in the
real world. As a rough cut of how we might reconcile usability and theory, I wonder if
the correct path is to have obsmarkers immediately hide things (if possible) only when
they're first introduced (likely through pull), but if the user takes an action that
unhides, we just do that and then there's some advisory mechanism by which they can be
told that things have been obsoleted.
I'm also confused by this kind of things. Another example is:
* pull a changeset to publish (hg phase -p)
* rebase it on top of the public head
* change your mind (because, for instance, tests fail)
* from this point, there's no simple way to get the original changeset
and, more importantly, remove the obsmarker that'd get exchanged upon
next push.
If I understood correctly, this issue would be solved by improving "hg
strip" to remove the obsmarker.
So far, I'm not seen a rational for hash-preservation been a -requirement-
nor a group of people agreeing it is a -requirement-.
Sure it would be nice, but "nice" is different from -required-.
This is probably a core point we need to iron out in this discussion.
I'm starting (based on the above rough edges that I've tripped on more than
once) to be of the opinion that supporting hash preservation is effectively
non-optional because of workflows people already have in their brains. It also
makes a bunch of cases in tools like histedit and commit --amend easier to
write (and harder for future extension authors to screw up!) to get that
working in a sensible way.
I also think that hash preservation would be nice when it comes local
operations. This is important when exchanging with others to prevent
information that should remain local to propagate. Basically, in my
example above or yours, we don't want to exchange our local round-trip
operations.
But if one happens to have exchanged (pushed at least, not sure about
pull) the information, I think it does not sound unreasonable that
unhiding a changeset changes its hash (unless there is another possible
mechanism, like the "layer on top of obsmarkers" in the plan document).
Apart from this case of local-only operations, it's not very clear to me
why hash preservation would so important.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
