Skip to content
Snippets Groups Projects
  1. Jan 16, 2014
  2. Jan 09, 2014
  3. Dec 01, 2013
  4. Jan 06, 2014
  5. Jan 04, 2014
  6. Jan 15, 2013
  7. Jan 04, 2014
  8. Jan 16, 2014
  9. Jan 07, 2014
  10. Jan 16, 2014
  11. Jan 07, 2014
  12. Nov 16, 2013
  13. Nov 17, 2013
    • Mads Kiilerich's avatar
      rebase: improve error message for --base being empty or causing emptiness · dc515784
      Mads Kiilerich authored
      Before it just said 'nothing to rebase'.
      
      Now 'if "base" is an empty set:
        abort: empty "base" revision set - can't compute rebase set
      
      If the set of changesets to rebase can't be found from "base", it will fail as
      before but with more explanation of what the problem was.
      
      The name of the "base" option is not obvious - it is more like "samples
      identifying the branch to rebase". The error messages for problems with the
      specified "base" value will use that term and might thus also not be obvious,
      but at least they are consistent with the option name. The name "base" will not
      be used if the base only was specified implicitly as the working directory
      parent.
      dc515784
    • Mads Kiilerich's avatar
      rebase: improve error message for empty --source set · 3bff26f6
      Mads Kiilerich authored
      Before, it just said 'nothing to rebase' in this case. Now, it aborts
      mentioning the reason: 'empty "source" revision set'.
      
      Specifying revisions that cannot be rebased is a 'soft' error, but specifying
      an empty set deserves an abort that explains exactly what the problem is.
      3bff26f6
  14. Nov 16, 2013
    • Mads Kiilerich's avatar
      rebase: improve error message for empty --rev set · a259f7b4
      Mads Kiilerich authored
      Before, it just said 'nothing to rebase' in this case. Now, it aborts
      mentioning the reason: 'empty "rev" revision set'.
      
      Specifying revisions that cannot be rebased is a 'soft' error, but specifying
      an empty set deserves an abort that explains exactly what the problem is.
      a259f7b4
  15. Nov 17, 2013
  16. Nov 21, 2013
    • Mads Kiilerich's avatar
      help: branch names primarily denote the tipmost unclosed branch head · 4edd179f
      Mads Kiilerich authored
      Was the behavior correct and the description wrong so it should be updated as
      in this patch? Or should the code work as the documentation says?
      
      Both ways could make some sense ... but none of them are obvious in all cases.
      
      One place where it currently cause problems is when the current revision has
      another branch head that is closer to tip but closed. 'hg rebase' refuses to
      rebase to that as it only see the tip-most unclosed branch head which is the
      current revision.
      
      /me kind of likes named branches, but no so much how branch closing works ...
      4edd179f
  17. Jan 12, 2014
    • Mads Kiilerich's avatar
      util: introduce util.debugstacktrace for showing a stack trace without crashing · 47d08436
      Mads Kiilerich authored
      This is often very handy when hacking/debugging.
      
      Calling util.debugstacktrace('hey') from a place in hg will give something like:
        hey at:
         ./hg:38                                     in <module>
         /home/user/hgsrc/mercurial/dispatch.py:28   in run
         /home/user/hgsrc/mercurial/dispatch.py:65   in dispatch
         /home/user/hgsrc/mercurial/dispatch.py:88   in _runcatch
         /home/user/hgsrc/mercurial/dispatch.py:740  in _dispatch
         /home/user/hgsrc/mercurial/dispatch.py:514  in runcommand
         /home/user/hgsrc/mercurial/dispatch.py:830  in _runcommand
         /home/user/hgsrc/mercurial/dispatch.py:801  in checkargs
         /home/user/hgsrc/mercurial/dispatch.py:737  in <lambda>
         /home/user/hgsrc/mercurial/util.py:472      in check
      ...
      47d08436
  18. Jan 07, 2014
  19. Nov 16, 2013
    • Mads Kiilerich's avatar
      bisect: --command without --noupdate should flag the parent rev it tested · 0d32dd60
      Mads Kiilerich authored
      14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it
      also changed how the 'current' revision is used in combination with --command.
      The new behaviour might be ok for --noupdate where the working directory and
      its revision shouldn't be used, but it also did that when --command is used to
      run a command on the currently checked out revision then it could register the
      test result on the wrong revision.
      
      An example:
      
      Before, bisect with --command could use the wrong revision when recording the
      test result:
      
        $ hg up -qr 0
        $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
        changeset 31:58c80a7c8a40: bad
        abort: inconsistent state, 31:58c80a7c8a40 is good and bad
      
      Now it works as before and as expected and uses the working directory revision
      for the --command result:
      
        $ hg up -qr 0
        $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
        changeset 0:b99c7b9c8e11: bad
        ...
      0d32dd60
    • Mads Kiilerich's avatar
      context: drop caching 'copies' method · d0097d58
      Mads Kiilerich authored
      The 'copies' method has no test coverage and calls copies.pathcopies with an
      incorrect number of parameters and is thus (fortunately) not used. Kill it.
      d0097d58
  20. Nov 19, 2013
  21. Nov 22, 2013
  22. Nov 19, 2013
    • Siddharth Agarwal's avatar
      commands.bookmarks: hold wlock for write operations · 5fe4c1a9
      Siddharth Agarwal authored
      Any invocations of bookmarks other than a plain 'hg bookmarks' will likely
      cause a write to the bookmark store. These should be guarded by the wlock.
      
      The repo._bookmarks read should be similarly guarded by the wlock if we're
      going to be subsequently writing to it.
      5fe4c1a9
Loading