1. 30 Jul, 2019 1 commit
  2. 29 Jul, 2019 2 commits
  3. 19 Jul, 2019 1 commit
    • Anton Shestakov's avatar
      prune: spell --successor flag without any unnecessary shortcuts · 184c64c81528
      Anton Shestakov authored
      If a user wants to spell out -s, it makes sense to allow that. Before this
      patch, prune would complain that --successor is not a recognized option.
      Obviously people don't usually need to spell --successors by hand thanks to
      shell completion (at least for Bash) using debugcomplete to see all available
      flags, so this patch doesn't bring any need for more typing.
      
      And thanks to Mercurial understanding shortened forms of command-line flags as
      long as they are unambiguous, the old-style `--succ` flags still work normally,
      and there are tests that use them. But two tests now use the full form to
      demonstrate that both ways work.
      184c64c81528
  4. 17 Jul, 2019 2 commits
    • Pierre-Yves David's avatar
      branching: merge with stable · 076b6813a7ea
      Pierre-Yves David authored
      076b6813a7ea
    • Sushil Khanchi's avatar
      touch: fix the inconsistent behavior of divergence catching logic (issue6107) · ef8907df73fc
      Sushil Khanchi authored
      When touching a node, the way we check if it can lead to divergence
      is we look at the successors sets of the rev being touched. And if
      there is successor revs exists (excluding the case when that successor
      set is (A,) for rev A) that means there will be divergence and we warn
      the user.
      This works fine but there is still a case (which is not covered by looking
      at successor sets) which can lead to divergence.
      
      That case is: when there is already a revision exists which is divergent
      to the revision being touched. And performing the touch would revive
      that "dead" divergence. (Dead because one of the revision is obsolete which
      is the one we are touching)
      
      And to see if there is any rev which is divergent to a particular rev
      we already have a function which we can use here
      i.e. `evolvecmd.divergentsets(repo, ctx_being_touched)`
      
      Changes in test file demonstrate the fixed behaviour.
      ef8907df73fc
  5. 13 Jul, 2019 1 commit
  6. 11 Jul, 2019 2 commits
    • Anton Shestakov's avatar
      fold: allow operations on merge commits with some conditions · 41885988921e
      Anton Shestakov authored
      It's possible to fold revision chains that include a single merge commit: just
      fold everything into the merge commit while saving its other parent (so it
      continues being a merge commit). It's also possible to fold revisions that
      include multiple merge commits, on the condition that they merge with not more
      than 2 external changesets (i.e. a changesets that aren't going to be folded).
      41885988921e
    • Anton Shestakov's avatar
      rewind: make sure merge commits include files from p1 and p2 · 7839720c7c75
      Anton Shestakov authored
      Otherwise rewinding a merge commit makes it lose all changes.
      
      This fix populates `updates` argument of rewriteutil.rewrite() with parent
      changesets. That argument is normally used for folding multiple changesets, but
      in this case it's simply used to include files from p1 and p2. Usually,
      rewrite() works fine using ctx.files(), but that function can return an empty
      list when ctx is a merge commit.
      7839720c7c75
  7. 09 Jul, 2019 1 commit
    • Anton Shestakov's avatar
      rewriteutil: allow rewriting merge commits (issue4561) · 0e0731406efd
      Anton Shestakov authored
      This patch simply allows rewriteutil.rewrite() to work with commits with
      multiple parents (i.e. merges). That function is used in such commands as fold,
      metaedit, touch, rewind.
      
      The issue 4561 is marked as easy, the limitation is called unnecessary, no
      tests fail after this change. What can go wrong.
      0e0731406efd
  8. 04 Jul, 2019 1 commit
  9. 25 Jun, 2019 1 commit
    • Sushil Khanchi's avatar
      evolve: fix confusion in branch heads checking logic when topic in play · 5f90eb8fd63c
      Sushil Khanchi authored
      To provide some context, when topics are in play the branchmap cache
      we store contains the branch info of a rev as "branch:topic" format IIUC.
      
      Assuming that is right, now in present code we don't actually cover
      this part that "when looking for branch heads where we also have active
      topic we should look for branch='branch_name:topic' instead".
      And we get wrong branch heads as a result.
      
      This patch make sure that we pass right candidate to find branch heads
      using branchmap.branchheads() by overriding the localrepo.branchheads()
      
      Changes in test file reflect the fixed behavior.
      5f90eb8fd63c
  10. 01 Jul, 2019 1 commit
  11. 16 Jun, 2019 1 commit
    • Sushil Khanchi's avatar
      evolve: fix the code flow pattern of solving obswdir par and troubled revs · 4c9f9dac8977
      Sushil Khanchi authored
      Now we will go to _handlenotrouble() (which prints messages about
      no revs to solve) only when there is no troubled revs and working
      dir parent is not obsolete.
      
      This change also saves us from an issue which was about looking into the
      revset (smartset contains troubled revs to solve) when a rev from the revset
      gets hidden. This happens in the case when our wdir parent is obsolete. After
      resolving obswdir parent we were looking into the revset to check if there is
      any troubled revs to solve but we should have performed this check before
      performing the obswdir resolution.
      
      Changes in test file reflect this fixed behaviour.
      4c9f9dac8977
  12. 14 Jun, 2019 1 commit
    • Anton Shestakov's avatar
      pick: register pickstate as an unfinished state · a9cf0ba6e6c7
      Anton Shestakov authored
      This way pickstate file will indicate that unfinished pick command needs to be
      dealt with (--continue or --abort) before modifying the repo. Otherwise it
      would be e.g. possible to commit during an interrupted pick and that's not
      expected.
      a9cf0ba6e6c7
  13. 18 Jun, 2019 1 commit
    • Anton Shestakov's avatar
      evolve: orphans that evolve into nothing don't need successors (issue5967) · 27947b17cfaf
      Anton Shestakov authored
      When continuing to solve an orphan that created no changes (i.e. clean wdir),
      _completeorphan() used to create an obsmarker that said that the result of that
      orphan evolution is the currently checked out changeset. That's not a correct
      obsmarker, because all of the orphan's changes were dropped and so it had no
      effect on the currently checked out changeset.
      
      This is an issue that has only existed when --continu'ing evolve, that's why
      the fix touches _completeorphan(), but not _solveunstable(). This fix is
      adapted from a similar "if node is None" block in _finalizerelocate().
      27947b17cfaf
  14. 07 Jun, 2019 1 commit
    • Anton Shestakov's avatar
      pick: remove transaction on the whole command (issue6037) · 313565dd75e3
      Anton Shestakov authored
      At its core, pick is a pretty straightforward and well-behaving command, it
      uses functions already in core hg, it checks that wdir is clean and that
      changeset to pick is not public, it checks if there happen to be merge
      conflicts and can be --continue'd later, etc.
      
      It is very similar to graft in core (it also uses mergemod.graft function), but
      it obsoletes the original changeset. However, graft does not experience this
      incorrect behavior from issue 6037.
      
      What happens in the test case for this issue when we pick a revision that
      touches both "a" and "b": mergemod.graft() takes the original changeset and
      tries to apply it to the wdir, which results in "b" being marked as newly added
      and ready to be committed, "a" updated with the new content and being marked as
      modified, but "a" also has conflicts. Pick correctly notices this and saves its
      state before asking for user intervention. So far so good. However, when the
      command raises InterventionRequired to print a user-facing message and exit
      while being wrapped in repo.transaction() context manager, the latter partially
      undoes what mergemod.graft() did: it unmarks "b" as added. And when user
      continues pick, "b" is therefore not tracked and is not included in the
      resulting commit.
      
      The transaction is not useful here, because it doesn't touch wdir (it's still
      dirty), it doesn't remove pickstate (and other commands will refuse to work
      until pick --abort or --continue), it just makes "b" untracked.
      
      The solution is to use repo.transaction() only to wrap code that writes data to
      hg store in the final stages of the command after all checks have passed and is
      not expected to fail on trivial cases like merge conflicts. For example,
      committing the picked changeset. But since pick uses repo.commit() for that,
      and because that function already uses a transaction, wrapping it in another
      transaction doesn't make sense.
      313565dd75e3
  15. 08 Jun, 2019 1 commit
  16. 06 Jun, 2019 3 commits
  17. 27 May, 2019 1 commit
    • Pierre-Yves David's avatar
      topic: add a simple option to reject publishing · 228caeb8b7af
      Pierre-Yves David authored
      The option is pretty basic but it can be used as base to build larger feature.
      The main target for going in this direction is to be able to distinct between
      user that are "simple contributors" pushing topic for review and the
      "maintainers" or "automation" that can publish changesets.
      228caeb8b7af
  18. 26 May, 2019 1 commit
    • Pierre-Yves David's avatar
      obsdiscovery: drop `obshash` discovery protocol (issue6136) · 77f3699e711e
      Pierre-Yves David authored
      The protocol has been superseeded by stablerange for a long time. It is untested
      and more and more buggy. Since this is deprecated experimental code in an
      experimental code, we drop it.
      
      We keep the underlying computation and debug command around for now. They might
      still be useful to looks at repositories
      77f3699e711e
  19. 27 May, 2019 1 commit
  20. 27 Apr, 2019 1 commit
  21. 26 Apr, 2019 1 commit
    • Pulkit Goyal's avatar
      topic: drop support for accessing csets in branch stack using bxx (issue6119) · c4097632a1a3
      Pulkit Goyal authored
      When topic extension is enabled and we have some cset whose hash is `b1234`,
      topic extension thinks that we are accessing 1234 cset in current branch stack.
      However that's not the case generally. Also I am not sure many people use this
      bxxx thing.
      
      Since we have a generic sxxx way to access csets, let's drop support for
      accessing csets using bxx which leads to bad behavior.
      
      Looking at the tests, we don't show bxxx in hg stack output anymore.
      
      I update the test to use sxxx instead of bxxxx.
      c4097632a1a3
  22. 19 Apr, 2019 1 commit
    • Martin von Zweigbergk's avatar
      evolve: run in a single transaction · d314deb12f08
      Martin von Zweigbergk authored
      This speeds up `hg evolve --all` of a stack of 24 commits in the hg
      repo from 11.5s to 3.7s (3x). As can be seen in the tests, it also
      avoid some warnings about transiently unstable commits.
      d314deb12f08
  23. 10 Apr, 2019 1 commit
  24. 24 Apr, 2019 3 commits
    • Anton Shestakov's avatar
      evolve: use --all by default (BC) · 3ef96578da43
      Anton Shestakov authored
      allopt defaults to None to avoid touching _checkevolveopts(). If it were True
      by default, that function would always act like the flag was provided by user,
      and so using --abort, --stop, --continue or --rev on their own would never work
      (hg evolve will complain that you cannot specify both --rev and --all).
      
      A notable change in tests is "no troubled changesets" line that gets printed
      when using `hg evolve` to update to the evolved successor of working directory
      parent, but there were no actual instabilities.
      3ef96578da43
    • Anton Shestakov's avatar
      bcd52ce0916d
    • Pierre-Yves David's avatar
      branching: merge with stable · 5e8c47c553db
      Pierre-Yves David authored
      VErsion 8.5.0 got released
      5e8c47c553db
  25. 23 Apr, 2019 2 commits
  26. 12 Mar, 2019 1 commit
    • Martin von Zweigbergk's avatar
      evolve: use merge.update() for resolving phase divergence · 63148e999562
      Martin von Zweigbergk authored
      Iterating over the manifest when tree manifests and narrowness is in
      play produces entries for paths outside the narrowspec that represent
      trees. For example, if the tests/ directory of the hg repo was not in
      the narrowspec (and the hg repo was using tree manifests, which it
      doesn't), then there would be a "tests/" entry in the manifest. The
      merge code deals with some of these cases. For example, it's valid to
      do a merge if only the local side changes directories outside the
      narrowspec. That allows rebasing a local commit onto a public commit
      that had changes to the excluded paths to work.
      
      However, _resolvephasedivergent() was iterating of the manifests,
      which resulted in crashes for some of our users when they tried to
      resolve phase-divergent commits (actually content-divergent commits
      that became phase-divergent after the intermediate rebase). We can fix
      that by relying on merge.update(), since that already handles this
      case.
      
      [This re-install a changeset backed out for compatibility reason]
      63148e999562
  27. 23 Apr, 2019 2 commits
  28. 19 Apr, 2019 1 commit
  29. 18 Apr, 2019 1 commit
  30. 17 Apr, 2019 1 commit
  31. 12 Apr, 2019 1 commit