[PATCH 1 of 2] strip: add a delayedstrip method that works in a transaction

Augie Fackler raf at durin42.com
Tue Jun 27 17:01:29 EDT 2017


On Tue, Jun 27, 2017 at 01:16:17PM -0700, Martin von Zweigbergk via Mercurial-devel wrote:
> On Tue, Jun 27, 2017 at 10:38 AM, Jun Wu <quark at fb.com> wrote:
> > Excerpts from Martin von Zweigbergk's message of 2017-06-26 21:33:50 -0700:
> >> >
> >> > If we abort, what do you think about the "hg rebase --continue" case in
> >> > issue5606? Should we *enforce* the user to turn on evolve to continue?
> >> > I don't think that is a good idea.
> >>
> >> Yes, either turn on evolve or abort the rebase (aborting the rebase
> >> was what I was thinking while writing the paragraph above, but
> >> continuing with evolve on should also be a solution). This is such a
> >> corner case that I don't care much.
> >
> > I think the key disagreement is whether should we "allowunstable" when
> > obsstore is disabled. I think for power users, if they explicitly ask for,
> > we should continue.
>
> I think allowduplicates is quite different from allowunstable. We can
> automate resolution of unstable commits, but we can't automate
> resolution of duplicates. I'm still convinced it's a bug in a the
> command that creates the duplicate commit (unless that's the command's
> purpose, of course, but then it really shouldn't attempt to strip one
> of the commits).
>
> >
> >> > [1]: https://bitbucket.org/facebook/hg-experimental/issues/6/hg-absorb-merges-diverged-commits
> >>
> >> I spent a few minutes, but I couldn't understand how it would break.
> >
> > It's similar to amend a non-head with obsstore disabled. He is a power user
> > that wants advanced stack editing without obsstore.
> >
> >> I'm not sure, but it's probably the person writing the "hg
> >> rebase-and-commit" command made the mistake. To me, just looking at
> >> the result from the user's perspective makes it clearly wrong. If the
> >> rebasing leaves both an old version and a new version in the repo, I
> >> would definitely say that there's a bug in the command.
> >
> > How about:
> >
> >   1. Add a way to allowunstable without evolve, maybe call it
> >      "allowduplicates" for power users that I care about.
> >   2. ProgrammingError if allowduplicates is not set (which is the default),
> >      but continue with warning if allowduplicates is set.
>
> As I said above, I don't think 1 is a good idea. Maybe I'm just being
> stubborn (I encourage a third party to step in and say that if that's
> the case), but I'd really prefer to make it just a ProgrammingError.
> If we ever come up with a valid use case, we can add add the
> allowduplicates config then (we'll know, because the user/developer
> ran into the exception).

I think it'd be fine to add a TODO that we should look for cases where
this is valid and try to constrain it - my gut reaction is that Jun is
right, and that it can't be a programming error if we ever allow
instability (which is sometimes useful for power users, and might be
useful if we get a little more smarts around defering stabilization of
changes.)

Does that make sense? Or have I not quite understood this conversation?


More information about the Mercurial-devel mailing list