Skip to content
Snippets Groups Projects
  1. Feb 05, 2019
  2. Feb 04, 2019
  3. Feb 06, 2019
  4. Feb 05, 2019
  5. Feb 03, 2019
  6. Feb 05, 2019
  7. Feb 02, 2019
    • Martin von Zweigbergk's avatar
      status: if ui.relative-paths=no, don't use relative paths even with patterns · 5f827e9ce870
      Martin von Zweigbergk authored
      Without ui.relative-paths or command.status.relative set, you get this
      behavior:
      
        hgext$ hg st
        M hgext/narrow/narrowrepo.py
        hgext$ hg st .
        M narrow/narrowrepo.py
        hgext$ hg st narrow
        M narrow/narrowrepo.py
      
      I think it's surprising that some of those produce relative paths. I
      suspect it works that way because "hg st ." was an easy way of getting
      relative paths. Perhaps not much thought was given to how it should
      behave when the pattern was not ".". It also feels wrong to conflate
      the request for relative patterns with matching of of patterns.
      
      Since we can now start fresh and define the behavior of
      ui.relative-paths as we want, I suggest we make ui.relative-paths=no
      consistently not give relative paths. So that's what this paths starts
      doing for `hg status`.
      
      Differential Revision: https://phab.mercurial-scm.org/D5802
      5f827e9ce870
  8. Jan 29, 2019
  9. Feb 02, 2019
    • Martin von Zweigbergk's avatar
      config: introduce a new value for ui.relative-paths getting old behavior · aec185af621e
      Martin von Zweigbergk authored
      The few places I've modified so far to respect ui.relative-paths have
      traditionally defaulted showing the path from the repo root. However,
      some commands (at least `hg files`) default to showing paths relative
      to the cwd. Let's allow a special value for ui.relative-paths to
      preserve the old behavior, so we can use that as default value for
      it. I don't expect that anyone would want to set this value, so
      perhaps we could have relied on it being unset, but I don't really
      like behaviors that can only be achieved by a unset config option.
      
      Differential Revision: https://phab.mercurial-scm.org/D5800
      aec185af621e
  10. Feb 05, 2019
  11. Feb 04, 2019
  12. Jan 21, 2019
  13. Feb 04, 2019
  14. Jan 27, 2019
  15. Jan 31, 2019
    • 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
    • Kyle Lippincott's avatar
      diff: when looking for diff configs, support a configurable prefix · 78b270a55dc6
      Kyle Lippincott authored
      In a future commit, I want to make it possible to have the diff options pulled
      from (as an example) `commands.commit.interactive.ignorews`; previously we only
      supported this for customizable sections (so this would have needed a
      `commit-interactive` section and been named `commit-interactive.ignorews`, which
      felt a bit weird.
      
      Differential Revision: https://phab.mercurial-scm.org/D5833
      78b270a55dc6
    • Kyle Lippincott's avatar
      config: extract diff-related coreconfigitem()s to a helper method · 901ebc81ffb3
      Kyle Lippincott authored
      We already have 'annotate' and 'diff' that use the same set of options, and I
      want to add more in a followup commit, so I'm attempting to reduce maintenance
      burden and duplication by making it possible to register all of them at once.
      
      Differential Revision: https://phab.mercurial-scm.org/D5832
      901ebc81ffb3
  16. Jan 29, 2019
    • 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
  17. Feb 04, 2019
Loading