Skip to content
Snippets Groups Projects
  1. Nov 04, 2020
  2. Jun 23, 2020
    • Martin von Zweigbergk's avatar
      copies: handle more cases where a file got replaced by a copy · 58e7ee23ddbd
      Martin von Zweigbergk authored
      This patch fixes the changeset-centric version in a pretty
      straight-forward way. It fixes it to automatically resolve the
      conflict, which is better than resulting in a modify/delete conflict
      as it was before b4057d001760 (merge: when rename was made on both
      sides, use ancestor as merge base, 2020-01-22).
      
      I'll leave it for later to test and explicitly handle cases where
      files have been renamed to the same target on different sides of the
      merge.
      
      Differential Revision: https://phab.mercurial-scm.org/D8653
      58e7ee23ddbd
    • Martin von Zweigbergk's avatar
      tests: test more cases where a file got replaced by a copy · 4b79e92a5ef8
      Martin von Zweigbergk authored
      This adds a test where a file is modified on one branch and is renamed
      onto another file in another branch. That should ideally be
      automatically resolved (by propagating the modification to the rename
      destination). Alternatively, it could be considered a modify/delete
      conflict. It should at least not be automatically resolved by ignoring
      the modification. However, that is what actually happens with the
      changeset-centric algorithm since I broke it in b4057d001760 (merge:
      when rename was made on both sides, use ancestor as merge base,
      2020-01-22). Before that commit, it resulted in a modify/delete
      conflict. The filelog-centric algorithm was broken already before that
      commit.
      
      Differential Revision: https://phab.mercurial-scm.org/D8652
      4b79e92a5ef8
  3. Oct 07, 2020
  4. Oct 20, 2020
  5. Oct 29, 2020
    • Dan Villiom Podlaski Christiansen's avatar
      commit: warn the user when a commit already exists · 976b26bdd0d8
      Dan Villiom Podlaski Christiansen authored
      Sometimes, a commit will result in an exact match of a preexisting
      commit, and if that commit isn't a branch head, hg will incorrectly
      note that it created a new head. Instead, we should warn the user that
      commit already existed in the repository.
      
      In practice, this bug is rather uncommon, and will only occur when the
      usr explicitly sets the date.
      
      Please note that this commit contains an API change to
      cmdutil.commitstatus()
      
      Differential Revision: https://phab.mercurial-scm.org/D9257
      976b26bdd0d8
  6. Oct 06, 2020
    • Jörg Sonnenberger's avatar
      revlog: don't cache parsed tuples in the C module · 4404f129341e
      Jörg Sonnenberger authored
      A cached entry creates ~8 Python objects per cached changeset, which
      comes to around 200 Bytes per cached changeset on AMD64. Especially for
      operations that touch a lot of changesets, that can easily sum up to
      more than a 100MB of memory. Simple tests on large repositories show
      <2% runtime penalty for ripping out the cache, even for cache heavy
      operations like "hg log" for all revisions.
      
      Differential Revision: https://phab.mercurial-scm.org/D9155
      4404f129341e
  7. Oct 16, 2020
  8. Sep 28, 2020
  9. Oct 26, 2020
  10. Oct 29, 2020
  11. Nov 02, 2020
  12. Oct 29, 2020
  13. Oct 13, 2020
  14. Oct 21, 2020
  15. Oct 29, 2020
  16. Oct 24, 2020
    • Matt Harbison's avatar
      repoview: only pin obsolete wdir parents while there are unresolved conflicts · 341e014fe0fb
      Matt Harbison authored
      I noticed after doing an update from an obsolete revision with a dirty wdir that
      the obsolete commit stayed visible for no obvious reason.  It was decided in
      85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in
      order to allow re-resolving.  Since the point of pinning the obsolete parents
      was to allow resolving in the first place (aaeccdb6e654), it makes sense to also
      gate it on whether or not there are any remaining files to resolve.  This might
      result in pinning again if files are marked unresolved again, but that seems
      reasonable, given that it still solves the original issue.
      
      Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is
      likely to cause complaints about pushing multiple heads or other unexpected
      errors.  So the faster it comes out of that state, the better.
      
      Differential Revision: https://phab.mercurial-scm.org/D9248
      341e014fe0fb
  17. Oct 28, 2020
  18. Oct 23, 2020
  19. Oct 29, 2020
  20. Oct 17, 2020
  21. Oct 13, 2020
  22. Oct 23, 2020
  23. Oct 20, 2020
  24. Oct 19, 2020
  25. Oct 18, 2020
  26. Oct 07, 2020
    • Pulkit Goyal's avatar
      tags: add safety check for len(record) while reading hgtagsfnodescache · 225e513c444e
      Pulkit Goyal authored
      I am trying to fix a breakage where somehow we end up getting a node of 12
      length from `getfnode()`. Understanding the hgtagsfnodescache code, it seems
      highly unlikely that it can happen unless one of `mctx.readfast().get()` or
      `ctx.filenode()` is returning a node of 12 length.
      
      For safety, I think it's better to add a check to make sure that record which we
      are parsing is of same length we are expecting otherwise we consider that as
      invalid record.
      
      Differential Revision: https://phab.mercurial-scm.org/D9169
      225e513c444e
Loading