Read about our upcoming Code of Conduct on this issue

This instance was upgraded to Heptapod 0.28.0 today

  1. 17 Jun, 2018 1 commit
    • Sangeet Kumar Mishra's avatar
      grep: add --diff flag · 7fbb5d76c555
      Sangeet Kumar Mishra authored
      Adds a diff flag, which works exactly same as all, in fact since
      --all searches diffs, there diff is a better name for it.
      The all flag is still here for backward compatibility reasons.
      Some major tests for all has been picked and added for diff.
      Differential Revision:
  2. 14 Jun, 2018 1 commit
  3. 03 May, 2018 2 commits
  4. 13 Jun, 2018 1 commit
    • Sangeet Kumar Mishra's avatar
      grep: adds allfiles mode · b8f45fc27370
      Sangeet Kumar Mishra authored
      Adds an allfiles flag that lets you grep on all files in the revision
      and not just the one that were modified in that changeset.
      This would work on a single revision and get all the files that were
      there in that revision. So it's like grepping on a previous state.
      Using this with wdir() :: `hg grep -r "wdir()" --allfiles` is what the
      default behavior is desired for grep.
      Support for multiple revisions to be added later.
      Differential Revision:
  5. 14 Jun, 2018 10 commits
  6. 08 Jun, 2018 1 commit
  7. 28 May, 2018 1 commit
    • Pulkit Goyal's avatar
      graft: add a new `--stop` flag to stop interrupted graft · 2ec44160165d
      Pulkit Goyal authored
      This patch adds a new flag `--stop` to `hg graft` command which stops the
      interrupted graft.
      The `--stop` flag takes back you to the last successful step i.e. it will keep
      your grafted commits, it will just clear the mergestate and interrupted graft
      The `--stop` is different from `--abort` flag as the latter also undoes all the
      work done till now which is sometimes not what the user wants.
      Suppose you grafted a lot of changesets, you encountered conflicts, you resolved
      them, did `hg graft --continue`, again encountered conflicts, continue, again
      encountered conflicts. Now you are tired of solving merge conflicts and want to
      resume this sometimes later. If you use the `--abort` functionality, it will
      strip your already grafted changesets, making you loose the work you have done
      resolving merge conflicts.
      A general goal related to this flag is to add this flag to `rebase` and
      `histedit` too. The evolve command already has this --stop flag.
      Tests are added for the new flag.
      .. feature::
         `hg graft` now has a `--stop` flag to stop interrupted graft.
      Differential Revision:
  8. 11 Jun, 2018 2 commits
    • Pulkit Goyal's avatar
      graft: fix the help text to say `graft reapplies previous options` · a8e7ea176437
      Pulkit Goyal authored
      The options which graft accepts are:
        * rev
        * continue
        * edit
        * log
        * force
        * currentdate
        * currentuser
        * date
        * user
        * tool
        * dryrun
      Out of these following should be reapplied in case conflicts occur and user does
      `hg graft --continue`:
        * rev
        * log
        * force
        * currentuser
        * currentdate
        * date
        * user
      rev and force were already reapplied by --continue. Some recent refactors made
      graft to store the values of other options in graftstate and reapplies them at
      `hg graft --continue`.
      Now all the options which should be reapplied are taken care of, we can easily
      remove the help note which says that `--continue does not reapply earlier
      options` and help text saying that we reapplies earlier options.
      ..  feature:: `hg graft --continue` now reapplies all the earlier options
          `hg graft` now preserves the value of all the flags and reapplies them in
          case of `hg graft --continue`.
      Differential Revision:
    • Martin von Zweigbergk's avatar
      locate: explicitly use dirstate.matches() for working copy · fa4a286410a5
      Martin von Zweigbergk authored
      `hg locate` is odd in that it includes files that have been removed
      from the working copy. It relies on workingctx.matches() for that. I
      want to make workingctx.matches() not include removed files, so this
      patch makes `hg locate` handle the working copy differently instead.
      Differential Revision:
  9. 25 May, 2018 1 commit
  10. 02 Jun, 2018 1 commit
  11. 30 May, 2018 1 commit
  12. 02 Jun, 2018 1 commit
  13. 24 May, 2018 1 commit
  14. 28 May, 2018 1 commit
    • Matt Harbison's avatar
      outgoing: pay attention to `default:pushurl` for bookmarks and subrepos · dfb888aae17a
      Matt Harbison authored
      The problem here was that `default:pushurl` and `default` get translated to a
      single entry in `ui.paths` named 'default', with an attribute for 'pushloc',
      'loc', and 'rawloc'.  ui.expandpath() then always takes the `rawloc` attribute.
      Maybe the ui.expandpath() API is busted and should be removed?  Or maybe
      getpath() should return a copy that adds an attribute reflecting the URL of the
      path chosen?
      I thought that I could remove the code in hg._outgoing() and pass the location
      resolved in as `dest`, but unfortunately that code is needed there
      to resolve #branch type URLs.  Maybe that should be pulled up to,
      because I can't see any reasonable behavior for a subrepo path that's
      constructed out of that type of URL.
      The push command already resolves this early, so that works properly.  But it
      looks like bundle, histedit, largefiles, patchbomb, and summary use a similar
      pattern, so they are likely similarly affected.
  15. 25 May, 2018 4 commits
    • Pulkit Goyal's avatar
      graft: drop --user and --date values info from hint in case of conflicts · 5736570718fe
      Pulkit Goyal authored
      After previous patch, we have started preserving user and date values in
      graftstate and reusing them during `hg graft --continue`. Now passing --user and
      --date again with --continue makes no sense. Let's drop them from the hint.
      Differential Revision:
    • Pulkit Goyal's avatar
      graft: reuse --user and --date values in `hg graft --continue` (BC) · decdb587ea12
      Pulkit Goyal authored
      Reading the user and date information from graftstate during `hg graft
      --continue` will help us in preserving the user and date arguments passed when
      `hg graft` was called. This patch reads that information and reuses that while
      running `hg graft --continue`. So after this patch, --user and --date values are
      preserved even if conflicts occur and user don't need to pass them again.
      The test changes demonstrate the fix.
      This is a backward incompatible change but I think of this more as a bug fix.
      Also thinking about removing the line from `hg help graft` which says --continue
      does not reapply other flags but need to check what are the other flags which
      needs to be preserved.
      Differential Revision:
    • Pulkit Goyal's avatar
      graft: store user passed date and user information in graftstate · 63553c2bef7e
      Pulkit Goyal authored
      Right now, `hg help graft` says:
      The -c/--continue option does not reapply earlier options, except for --force.
      which should be treated as a bug.
      A good user experience is that the commands remember the arguments passed
      initially and preserve them during `hg graft --continue`.
      This patch starts storing the user and date information in graftstate if user
      passed it. Upcoming patches will make sure we preserve that information during
      --continue and them don't allow user to pass any new arguments with --continue.
      I don't think there is any another `--continue` flag which allows new options to
      be passed with it.
      Differential Revision:
    • Pulkit Goyal's avatar
      graft: use cmdstate.delete() to delete the state file · 0dfa27e53c57
      Pulkit Goyal authored
      Previous patches start using state.cmdstate() class for statefiles. The class
      has a function delete() to delete the state file. This patch replaces the
      existing repo.vfs.unlink() with that delete() function.
      Differential Revision:
  16. 18 Apr, 2018 1 commit
  17. 13 Apr, 2018 1 commit
    • Yuya Nishihara's avatar
      log: fix crash on empty revision with --copies switch · 141017c7f7a9
      Yuya Nishihara authored
      If a revset is empty, .max() raises ValueError.
      I don't see any reason to recompute the revs, so I made it reuse the one
      returned by logcmdutil.getrevs(). If no revs specified by command line,
      the endrev will be smartset.spanset(repo) + 1, which is basically the same
      as len(repo), the default of getrenamedfn(). If --follow specified,
      revs.max() points to the working parent, which seems more correct.
  18. 17 Apr, 2018 2 commits
  19. 15 Apr, 2018 1 commit
  20. 22 Mar, 2018 1 commit
  21. 14 Apr, 2018 1 commit
    • Gregory Szorc's avatar
      registrar: replace "cmdtype" with an intent-based mechanism (API) · dfc51a482031
      Gregory Szorc authored
      Commands perform varied actions and repositories vary in their
      Historically, the .hg/requires file has been used to lock out clients
      lacking a requirement. But this is a very heavy-handed approach and
      is typically reserved for cases where the on-disk storage format
      changes and we want to prevent incompatible clients from operating on
      a repo.
      Outside of the .hg/requires file, we tend to deal with things like
      optional, extension-provided features via checking at call sites.
      We'll either have checks in core or extensions will monkeypatch
      functions in core disabling incompatible features, enabling new
      features, etc.
      Things are somewhat tolerable today. But once we introduce alternate
      storage backends with varying support for repository features and
      vastly different modes of behavior, the current model will quickly
      grow unwieldy. For example, the implementation of the "simple store"
      required a lot of hacks to deal with stripping and verify because
      various parts of core assume things are implemented a certain way.
      Partial clone will require new ways of modeling file data retrieval,
      because we can no longer assume that all file data is already local.
      In this new world, some commands might not make any sense for certain
      types of repositories.
      What we need is a mechanism to affect the construction of repository
      (and eventually peer) instances so the requirements/capabilities
      needed for the current operation can be taken into account. "Current
      operation" can almost certainly be defined by a command. So it makes
      sense for commands to declare their intended actions.
      This commit introduces the "intents" concept on the command registrar.
      "intents" captures a set of strings that declare actions that are
      anticipated to be taken, requirements the repository must possess, etc.
      These intents will be passed into hg.repo(), which will pass them into
      localrepository, where they can be used to influence the object being
      created. Some use cases for this include:
      * For read-only intents, constructing a repository object that doesn't
        expose methods that can mutate the repository. Its VFS instances
        don't even allow opening a file with write access.
      * For read-only intents, constructing a repository object without
        cache invalidation logic. If the repo never changes during its lifetime,
        nothing ever needs to be invalidated and we don't need to do expensive
        things like verify the changelog's hidden revisions state is accurate
        every time we access repo.changelog.
      * We can automatically hide commands from `hg help` when the current
        repository doesn't provide that command. For example, an alternate
        storage backend may not support `hg commit`, so we can hide that
        command or anything else that would perform local commits.
      We already kind of had an "intents" mechanism on the registrar in the
      form of "cmdtype." However, it was never used. And it was limited to
      a single value. We really need something that supports multiple
      intents. And because intents may be defined by extensions and at this
      point are advisory, I think it is best to define them in a set rather
      than as separate arguments/attributes on the command.
      Differential Revision:
  22. 24 May, 2018 3 commits
  23. 15 May, 2018 1 commit