Commit Graph

8 Commits (e8f70f25df0d14de60e750a1b3fdf5f2944ff32c)

Author SHA1 Message Date
Toshio Kuratomi b7522c5a1c Fix hg for python3 (#4528)
* Remove import of unused ConfigParser (ConfigParser has been renamed in py3)
* When retrieving version, normalize to a native string
2016-12-08 11:24:53 -05:00
Michael Scherer b788f45b49 Use the proper type for 'dest' argument 2016-12-08 11:24:28 -05:00
Jordi Gutiérrez Hermoso 4682ea1c3c hg: discard changes without changing the current revision
The command `hg up -C` by default moves to the latest revision on the
current branch. The `discard` function was trying to update to a
different branch, in case it was provided, by passing a `-r REVISION`
argument. Not only is this not the intended effect of the `discard`
function, but this also could update to a different branch that hasn't
been pulled yet, which is how we were experiencing trouble.

Instead, we unconditionally do `hg up -C -r .` to "update" to the
current revision (i.e. to "."), while `-C/--clean`ing the current
directory. This is similar to `hg revert --all`, except that it also
undoes the merge state of the working directory, in case there was
any.
2016-12-08 11:23:57 -05:00
Chris AtLee e7af5d2384 Add support for 'update' parameter to hg module 2016-12-08 11:23:24 -05:00
Greg DeKoenigsberg eb881d7d5d Proper author info for all remaining modules 2016-12-08 11:23:07 -05:00
Toshio Kuratomi 52d769d36c Reverse the force parameter for the hg module 2016-12-08 11:22:40 -05:00
Nate Coraor 771fdfb1f8 Fix a few bugs and misbehavior in the hg module: 1. Don't pull when `dest` is already at the desired changeset. 2. Don't change the working copy when cleaning or pulling and a revision was specified. 3. Change the default for the `revision` param to match the behavior of hg. 2016-12-08 11:22:36 -05:00
Michael DeHaan 213e518165 file extensions! 2016-12-08 11:22:22 -05:00