This instance will be upgraded to Heptapod 0.21.0rc2 on 2021-04-16 at 14:00 UTC+2 (a few minutes of down time)

  1. 22 Oct, 2020 1 commit
  2. 17 Nov, 2020 1 commit
  3. 13 Nov, 2020 2 commits
  4. 16 Nov, 2020 1 commit
  5. 12 Oct, 2020 1 commit
  6. 27 Oct, 2020 2 commits
  7. 17 Dec, 2019 1 commit
  8. 20 Jun, 2019 1 commit
  9. 27 Aug, 2019 2 commits
    • Kyle Lippincott's avatar
      split: handle partial commit of renames when doing split or record (issue5723) · 3cf091843b4f
      Kyle Lippincott authored
      When using split or record, using either interface (text or curses), selecting
      portions of the file to be committed/recorded did not work; the entire file was
      treated as having been selected. This was because the logic for handling partial
      application of the patches relies on knowing what files are "new with
      modifications" and it doesn't treat "rename destination" as "new".
      
      There was a complicating issue, however. We're relying on the patch header
      specifying the copy from/to information, which works as long as the 'copy from'
      file is there. In the case of renames, however, the 'rename from' file is *not*
      there, so we need to add it back.
      
      Differential Revision: https://phab.mercurial-scm.org/D6768
      3cf091843b4f
    • Kyle Lippincott's avatar
      split: handle partial commit of copies when doing split or record · 1fd530b1e1cf
      Kyle Lippincott authored
      When using split or record, using either interface (text or curses), selecting
      portions of the file to be committed/recorded did not work; the entire file was
      treated as having been selected. This appears to be because the logic for
      handling partial application of the patches relies on knowing what files are
      "new with modifications", and it doesn't treat "copy destination" as "new".
      
      Handling renames correctly is more difficult and will be done in a later patch.
      
      Differential Revision: https://phab.mercurial-scm.org/D6767
      1fd530b1e1cf
  10. 15 Jan, 2018 1 commit
    • Martin von Zweigbergk's avatar
      evolution: report new unstable changesets · 1a09dad8b85a
      Martin von Zweigbergk authored
      This adds a transaction summary callback that reports the number of
      new orphan, content-divergent and phase-divergent changesets.
      
      The code for reporting it is based on the code from the evolve
      extension, but simplified a bit. It simply counts the numbers for each
      kind of instability before and after the transaction. That's obviously
      not very efficient, but it's easy to reason about, so I'm doing this
      as a first step that can make us quite confident about the test case
      changes. We can optimize it later and make sure that the tests are not
      affected. The code has been used in the evolve extension for a long
      time and has apparently been sufficiently fast, so it doesn't seem
      like a pressing issue.
      
      Unlike the evolve extension's version of this report, this version
      applies to all commands (or all transactions run as part of any
      command, to be exact).
      
      Differential Revision: https://phab.mercurial-scm.org/D1867
      1a09dad8b85a
  11. 03 Mar, 2019 1 commit
    • Sushil Khanchi's avatar
      patch: include flag-only file changes in "special" when filtering (issue5864) · f8c5225b9054
      Sushil Khanchi authored
      This patch fix the issue5864 (or maybe issue5865 too) which occurs during
      split (or I should say at the time of filtering the hunks in interactive
      mode) where user hits a not ending loop of "no changes to record".
      And it's not only the case for split it will happen in every interactive
      case for e.g. `hg commit -i` or `hg uncommit -i`
      
      After looking into code I found that when filtering we have some
      notation called "special" for the file headers which doesn't contain
      any hunk and just contain the header (for e.g. newly added empty file
      or deleted file) where the user cannot change the content of operation.
      
      And I think we can put this "flag-only" file change in that same bucket
      of "special". But I doubt a bit about the case when a file have flag change
      and atleast one hunk then user won't be able to separate the flag change
      from hunks.
      Changed test file reflect the fixed behaviour.
      
      Differential Revision: https://phab.mercurial-scm.org/D6058
      f8c5225b9054
  12. 09 Mar, 2019 1 commit
  13. 03 Mar, 2019 1 commit
  14. 31 Jan, 2019 1 commit
    • Kyle Lippincott's avatar
      commit: if interactive, look elsewhere for whitespace settings (BC) · 66399f2e92aa
      Kyle Lippincott authored
      Previously, when doing `commit -i`, we respected `diff.ignorews` and other
      whitespace-related settings, which is probably unexpected. The primary reason
      for this is to support hgext.record's commandline options, it's probably
      accidental that the `[diff]` settings were also considered. See comments on
      issue6042 and D5490. This can cause problems (issue5839, issue6042).
      
      It is assumed by the author that the `[diff]` section is primarily for *viewing*
      diffs, and that it is unlikely what people intend when attempting to commit or
      revert.
      
      With this change, if a user wants the behavior, they can clone their `[diff]`
      settings to `commands.commit.interactive.<setting>`. This is thus a mild BC
      change, but one I suspect is not going to be relied on by anyone.
      
      Note: while doing a partial commit/revert, we do not know what command the user
      is actually running. This means that the split extension, which ends up calling
      into this code, will respect the `commands.commit.interactive.<setting>`
      settings, and not a hypothetical `commands.split.interactive.<setting>`. This
      *also* means that setting `commands.commit.interactive.ignoreblanklines`, for
      example, will still cause issue5839. Considering the highly unlikely chance that
      a user actually sets `commands.commit.interactive.<setting>`, the author deems
      this risk acceptable.
      
      Differential Revision: https://phab.mercurial-scm.org/D5834
      66399f2e92aa
  15. 29 Jan, 2019 2 commits
    • Kyle Lippincott's avatar
      commit: ignore diff whitespace settings when doing `commit -i` (issue5839) · 3a01ce246ece
      Kyle Lippincott authored
      Previously, we respected options like `diff.ignoreblanklines` and
      `diff.ignorews`.  This can cause problems when the user is attempting to
      actually commit the blank line change. Specifically, the split extension can get
      into an infinite loop because it detects that the working copy is not clean, but
      when we get the diff we don't see the changes, so it just skips popping up the
      chunk selection flow, saying there's no changes to record.
      
      These options are primarily meant for viewing diffs; it is highly unlikely that
      someone is actually intending to add extraneous whitespace and have it ignored
      if they attempt to interactively commit (but *not* ignored if they
      non-interactively commit).
      
      Differential Revision: https://phab.mercurial-scm.org/D5744
      3a01ce246ece
    • Kyle Lippincott's avatar
      patch: handle 0 context lines (diff.unified=0) when parsing patches · d1d3094b54f9
      Kyle Lippincott authored
      Previously, if there were no context lines, we would just keep updating the
      ranges and the hunk, but not actually storing the hunk (just overwriting it each
      time).  Thus a diff like this:
      
          $ hg diff --config diff.unified=0
          diff --git a/bar b/bar
          --- a/bar
          +++ b/bar
          @@ -1,0 +2,1 @@ 1
          +change1
          @@ -3,0 +5,1 @@ 3
          +change2
      
      would come out of the parser like this (change1 is lost):
      
          bar:
          @@ -3,0 +5,1 @@ 3
          +change2
      
      This had some really weird side effects for things like commit --interactive,
      split, etc.
      
      Differential Revision: https://phab.mercurial-scm.org/D5743
      d1d3094b54f9
  16. 22 Dec, 2017 2 commits
    • Anton Shestakov's avatar
    • Matt Harbison's avatar
      test-split: stabilize for Windows · 8d05705bde0a
      Matt Harbison authored
       - $PYTHON needs to be quoted when used as an executable in $HGEDITOR.  This
         avoids the error "'c' is not recognized as an internal or external command".
      
       - seq.py is printing out CRLF, and then the subsequent `sed` script seems to
         convert to LF on MSYS.  IDK if python print statements can be made to print
         LF on Windows, and I'm pretty sure CRLF is baked into some other tests.
      
       - A stray glob was causing the 'obsstore-off' case to report 'no result code
         from test'.
      
       - When I ran with --debug, the `hg diff` commands in the test both printed
         color sequences, and paused the output as it was run through the pager.
      8d05705bde0a
  17. 25 Jun, 2017 1 commit
    • Jun Wu's avatar
      split: new extension to split changesets · 02ea370c2baa
      Jun Wu authored
      This diff introduces an experimental split extension to split changesets.
      
      The implementation is largely inspired by Laurent Charignon's implementation
      for mutable-history (changeset 9603aa1ecdfd54b0d86e262318a72e0a2ffeb6cc [1])
      
      This version contains various improvements:
      
        - Rebase by default.
          This is more friendly for new users. Split won't lead to merge conflicts
          so a rebase won't give the user more trouble.
          This has been on by default at Facebook for months now and seems to be a
          good UX improvement.
          The rebase skips obsoleted or orphaned changesets, which can avoid
          issues like allowdivergence, merge conflicts, etc. This is more flexible
          because the user can decide what to do next (see the last test case in
          test-split.t)
      
        - Remove "Done split? [y/n]" prompt.
          That could be detected by checking `repo.status()` instead.
      
        - Works with obsstore disabled.
          Without obsstore, split uses strip to clean up old nodes, and it can
          even handle split a non-head changeset with "allowunstable" disabled,
          since it runs a rebase to solve the "unstable" issue in a same
          transaction.
      
        - More friendly editor text.
          Put what has been already split into the editor text so users won't lost
          track about where they are.
      
      [1]: https://bitbucket.org/marmoute/mutable-history/commits/9603aa1ecdfd54b
      
      Differential Revision: https://phab.mercurial-scm.org/D1082
      02ea370c2baa
  18. 19 Jun, 2018 1 commit
    • Martin von Zweigbergk's avatar
      split: preserve phase of commit that is being split · 4f885770c4a2
      Martin von Zweigbergk authored
      With this change, hg split will preserve the phase of the commit that is being
      split, ignoring the phases.new-commit setting. Previously, we would use whatever
      phases.new-commit was set to (unless our parent was secret, then we would be
      secret even if phases.new-commit=draft).
      
      Now, splitting a draft commit with phases.new-commit=secret does not cause the
      new commits to become secret, and splitting a secret commit with
      phases.new-commit=draft and a draft parent does not cause the new commits to
      become draft.
      
      Test cases and commit message taken from Kyle Lippincott's D2016 (thanks!).
      
      Differential Revision: https://phab.mercurial-scm.org/D3819
      4f885770c4a2
  19. 02 Feb, 2018 1 commit
  20. 19 Sep, 2018 1 commit
  21. 03 Mar, 2018 1 commit