- Nov 12, 2015
-
-
Augie Fackler authored
localrepo.parents() has relatively few users, and most of those were actually implicitly looking at the wctx, which is now made explicit via repo[None].
-
Augie Fackler authored
-
Augie Fackler authored
hg.py was the only remaining caller of localrepo.clone(), so it's time to move some more behavior out of localrepo.
-
- Dec 01, 2015
-
-
Siddharth Agarwal authored
It makes far more sense to leave these conflicts unresolved and kick back to the user than to just assume that the local version be chosen. There are almost certainly buggy scripts and applications using Mercurial in the wild that do merges or rebases non-interactively, and then assume that if the operation succeeded there's nothing the user needs to pay attention to.
-
- Nov 30, 2015
-
-
Siddharth Agarwal authored
We're going to make this option the default in an upcoming patch.
-
Siddharth Agarwal authored
'Regular' here means anything that isn't a change/delete prompt. We'll add this option to change/delete prompts in a subsequent patch.
-
- Nov 25, 2015
-
-
Siddharth Agarwal authored
Just like binary and symlink conflicts, change/delete conflicts influence the tool picked.
-
- Nov 28, 2015
-
-
Anton Shestakov authored
A block of code above this one already says "if fctx is not None", and it's also what this code actually intends to check, so let's be specific as PEP-8 recommends.
-
Anton Shestakov authored
6ddc86eedc3b didn't remove it, let's do it now. Placing the added lines into the already existing "if fctx is not None" block also makes webcommands.comparison() look a bit more like webcommands.filediff(), which eases possible future refactoring. And fctx is not None only when path in ctx, so logically it's equivalent.
-
Anton Shestakov authored
When comparing a file that was removed at the current revision, parents used to show grandparents instead, due to how fctx was "shifted" from the current revision to its p1. Let's not do that. The fix is pretty much copied from webcommands.filediff().
-
- Dec 01, 2015
-
-
Laurent Charignon authored
Before this patch we were using the deprecated bookmarks.write api. This patch replaces the call to bookmarks.write by a call to bookmarks.recordchange. We move the bookmark code above the code removing the undo file because with bookmarks.recordchange we have to create a transaction that would create an undo file.
-
Laurent Charignon authored
When I moved crecord into core, I didn't include the toggleAmend function (to switch from commit to amend mode). I did it because it would have made it more difficult to use record and crecord interchangably. This patch reintroduces the amend mode for commit -i as well as two tests to verify the behavior of the function.
-
Laurent Charignon authored
Before this patch, the chunkselector for record or crecord was used to return the list of hunks that were selected by the user. The goal of this series is to reintroduce the toggle amend feature for crecord. To do so, we need to be able to return more than just the selected hunks from the chunkselector but also the information: is amend mode toggled. This patch adds a new return value for chunkselectors that will be used to implement the toggle amend feature in crecord.
-
- Nov 21, 2015
-
-
Mykola Nikishov authored
For instance, Emacs allows to open file with special features enabled (AKA mode) based on the path/name of the file [1]. For such cases, use 'hg-histedit-XXX.txt' as filename pattern. [1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Choosing-Modes.html
-
Mykola Nikishov authored
By default, editor will use temp file named after hard-coded pattern 'hg-editor-XXX.txt' which makes it impossible for extensions to use another filename if desired. Now the middle part of the pattern ('editor') can be changed by setting extra['prefix'].
-
- Nov 30, 2015
- Nov 29, 2015
- Nov 28, 2015
-
-
Mike Edgar authored
The new extra propagation needs to be accounted for in cmdutil.amend, when checking for a no-changes fast-path.
-
Mike Edgar authored
-
Mike Edgar authored
This corrects extra propagation for the rebase command and the shelve command.
-
- Nov 25, 2015
-
-
Mathias De Maré authored
-
Mathias De Maré authored
-
Mathias De Maré authored
-
- Nov 24, 2015
-
-
Gregory Szorc authored
As the author of several 3rd party extensions, I frequently see bug reports from users attempting to run my extension with an old version of Mercurial that I no longer support in my extension. Oftentimes, the extension will import just fine. But as soon as we run extsetup(), reposetup(), or get into the guts of a wrapped function, we encounter an exception and abort. Today, Mercurial will print a message about extensions that don't have a "testedwith" declaring explicit compatibility with the current version. The existing mechanism is a good start. But it isn't as robust as I would like. Specifically, Mercurial assumes compatibility by default. This means extension authors must perform compatibility checking in their extsetup() or we wait and see if we encounter an abort at runtime. And, compatibility checking can involve a lot of code and lots of error checking. It's a lot of effort for extension authors. Oftentimes, extension authors know which versions of Mercurial there extension works on and more importantly where it is broken. This patch introduces a magic "minimumhgversion" attribute in extensions. When found, the extension loading mechanism will compare the declared version against the current Mercurial version. If the extension explicitly states we require a newer Mercurial version, a warning is printed and the extension isn't loaded beyond importing the Python module. This causes a graceful failure while alerting the user of the compatibility issue. I would be receptive to the idea of making the failure more fatal. However, care would need to be taken to not criple every hg command. e.g. the user may use `hg config` to fix the hgrc and if we aborted trying to run that, the user would effectively be locked out of `hg`! A potential future improvement to this functionality would be to catch ImportError for the extension/module and parse the source code for "minimumhgversion = 'XXX'" and do similar checking. This way we could give more information about why the extension failed to load.
-
- Nov 25, 2015
-
-
timeless authored
-
- Oct 31, 2015
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
The next patch will merge the cmdutil.service() calls of both commandserver and hgweb. Before doing it, this patch wipes out the code specific to hgweb from commands.serve().
-
Yuya Nishihara authored
This avoids the deep import of hgweb.server at the commands module.
-
- Nov 25, 2015
-
-
Siddharth Agarwal authored
We have finally laid all the groundwork to make this happen. The only change/delete conflicts that haven't been moved are .hgsubstate conflicts. Those are trickier to deal with and well outside the scope of this series. We add comprehensive testing not just for the initial selections but also for re-resolves and all possible dirstate transitions caused by merge tools. That testing managed to shake out several bugs in the way we were handling dirstate transitions. The other test changes are because we now treat change/delete conflicts as proper merges, and increment the 'merged' counter rather than the 'updated' counter. I believe this is the right approach here. For third-party extensions, if they're interacting with filemerge code they might have to deal with an absentfilectx rather than a regular filectx. Still to come: - add a 'leave unresolved' option to merges - change the default for non-interactive change/delete conflicts to be 'leave unresolved' - add debug output to go alongside debug outputs for binary and symlink file merges
-
Siddharth Agarwal authored
We're going to use this to verify the merge state in upcoming patches.
-
Siddharth Agarwal authored
We're going to use this for tests in upcoming patches.
-
- Nov 30, 2015
-
-
Siddharth Agarwal authored
This is so much easier to read than a long string of zeroes, and we're going to have a lot more of these nodes once change/delete conflicts are part of the merge state.
-
- Nov 24, 2015
-
-
Siddharth Agarwal authored
We're going to soon compare the output of all the non-orig files before and after a resolve, and this makes that more convenient. The .orig files are obviously going to differ between the two.
-
Siddharth Agarwal authored
See the previous patch for why we do this.
-
- Nov 30, 2015
-
-
Siddharth Agarwal authored
This is somewhat different from the currently existing 'a' action, for the following case: - dirty working copy, with file 'fa' added and 'fm' modified - hg merge --force with a rev that neither has 'fa' nor 'fm' - for the change/delete conflicts we pick 'changed' for both 'fa' and 'fm'. In this case 'branchmerge' is true, but we need to distinguish between 'fa', which should ultimately be marked added, and 'fm', which should be marked modified. Our current strategy is to just not touch the dirstate at all. That works for now, but won't work once we move change/delete conflicts to the resolve phase. In that case we may perform repeated re-resolves, some of which might mark the file removed or remove the file from the dirstate. We'll need to re-add the file to the dirstate, and we need to be able to figure out whether we mark the file added or modified. That is what the new 'am' action lets us do.
-
Siddharth Agarwal authored
This is going to be useful in an upcoming patch. We make this a public accessor because this is also going to be useful for custom merge drivers.
-
Siddharth Agarwal authored
We don't want to inadvertently return the workingctx (self._repo[None]).
-
timeless authored
try to clarify how to enable/disable the pager
-