- Oct 06, 2015
-
-
timeless authored
-
- Sep 30, 2015
-
-
Matt Mackall authored
-
- Sep 24, 2015
-
-
timeless authored
-
- Sep 15, 2015
-
-
Laurent Charignon authored
This patch avoids unnecessary conflicts to resolve during rebase for the users of changeset evolution. This patch modifies rebase to skip obsolete commits if they are being rebased on their successors. It introduces a new rebase state 'revprecursor' for these revisions that are being skipped and a new message to inform the user of what is happening. This feature is gated behind the config flag experimental.rebaseskipobsolete When an obsolete commit is skipped, the output is: not rebasing 14:9ad579b4a5de "I", already in destination as 17:fc37a630c901 "K"
-
- Sep 17, 2015
-
-
Pierre-Yves David authored
This is the first step toward making the "default destination" logic more clear and unified. The revset is private because I'm happy to delay the bikeshedding until after the clean up happened.
-
- Sep 01, 2015
-
-
liscju authored
Before this patch rebase --continue with specified --tool option outputs warnings "tool option will be ignored". It is false statement because in case of any merge conflicts it uses specified tool to resolve it. This patch makes this warning appears only when user specified --tool when running rebase --abort , in this case tool doesn't have any sense
-
- Aug 11, 2015
-
-
Pierre-Yves David authored
Running `hg pull --rebase` would move bookmarks without any repository locking. So we now lock the repository. For good measure and avoiding sneaky race conditions, we lock the repository for the whole operation. There is no code change besides the indentation.
-
- Jun 24, 2015
-
-
Gregory Szorc authored
Python 2.6 introduced the "except type as instance" syntax, replacing the "except type, instance" syntax that came before. Python 3 dropped support for the latter syntax. Since we no longer support Python 2.4 or 2.5, we have no need to continue supporting the "except type, instance". This patch mass rewrites the exception syntax to be Python 2.6+ and Python 3 compatible. This patch was produced by running `2to3 -f except -w -n .`.
-
- Jun 01, 2015
-
-
Jordi Gutiérrez Hermoso authored
The phrase "cannot edit immutable changeset" is kind of tautological. Of course unchangeable things can't be changed. We instead mention "public" and provide a hint so that we can point to the actual problem. Even in cases where some operation other than edition cannot be performed, "public" gives the root cause that results in the "immutable" effect. There is a precedent for saying "public" instead of "immutable", for example, in `hg commit --amend`.
-
- Apr 28, 2015
-
-
Augie Fackler authored
Extension authors (notably at companies using hg) have been cargo-culting the `testedwith = 'internal'` bit from hg's own extensions, which then defeats our "file bugs over here" logic in dispatch. Let's be more aggressive about trying to give extension authors a hint about what testedwith should say.
-
- May 15, 2015
-
-
Matt Mackall authored
-
Tony Tung authored
After a rebase --abort, we attempt to restore the previously active bookmark. We need to ensure that the bookmark still exists.
-
Tony Tung authored
-
- May 14, 2015
-
-
Matt Mackall authored
-
- May 10, 2015
-
-
Jordi Gutiérrez Hermoso authored
The check of the inrebase function was not correct, and it failed to consider the situation in which nothing has been rebased yet, *and* the working dir had been updated away from the initial revision. But this is easy to fix. Given the rebase state, we know exactly where we should be standing: on the first unrebased commit. We check that instead. I also took the liberty to rename the function, as "inrebase" doesn't really describe the situation: we could still be in a rebase state yet the user somehow forcibly updated to a different revision. We also check that we're in a merge state, since an interrupted merge is the only "safe" way to interrupt a rebase. If the rebase got interrupted by power loss or whatever (so there's no merge state), it's still safer to not blow away the working directory.
-
- May 12, 2015
-
-
Nat Mote authored
histedit and strip already have a short option for keep, so this makes the interface more consistent
-
- May 07, 2015
-
-
Katsunori FUJIWARA authored
Before this patch, "rebase.concludenode()" uses "dirstate.invalidate()" as a kind of "restore .hg/dirstate to the original status" during a failure. But it just discards changes in memory, and doesn't actually restore ".hg/dirstate". Then, it can't work as expected, if "dirstate.write()" is executed while processing. This patch uses "dirstateguard" instead of "dirstate.invalidate()" to restore ".hg/dirstate" during a failure even if "dirstate.write()" is executed before a failure. This patch also removes "beginparentchage()" and "endparentchange()", because "dirstateguard" makes them useless. This is a part of preparations to fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hook). After this patch, the changed dirstate becomes visible to external "precommit" hooks during "hg rebase" in "test-largefiles-misc.t", because "dirstateguard()" writes it out. But this content isn't yet correct, because: - "normal3" should be marked as "A"(dded) at committing It is newly added in the changeset being rebased. - but it is marked as "M"(odified) The result of "repo.setparents()" after "dirstateguard()" isn't yet written out before "precommit". So, merging is still in progress for "hg status" in it. This causes marking the file newly added on "other" branch as "A". This will be fixed by subsequent patch.
-
- Apr 14, 2015
-
-
Ryan McElroy authored
Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
-
Ryan McElroy authored
Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
-
Ryan McElroy authored
Today, the terms 'active' and 'current' are interchangeably used throughout the codebase in reference to the active bookmark (the bookmark that will be updated with the next commit). This leads to confusion among developers and users. This patch is part of a series to standardize the usage to 'active' throughout the mercurial codebase and user interface.
-
- Apr 28, 2015
-
-
Gregory Szorc authored
`hg pull` takes an optional "source" argument to define the path/url to pull from. Under some circumstances, this option could get proxied to rebase and interpretted as the --source argument to rebase, leading to unexpected behavior. In my local environment, "source" always appears in "opts" in pullrebase. However, when attempting to write a test, I couldn't reproduce this. Instead, the source is being captured as a positional argument in "args." I suspect an interaction between **kwargs and an extension is to blame for the differences in behavior. This is why no test has been written. I have tested behavior locally and the patch has the intended side-effect of making `hg pull --rebase` work again.
-
- Apr 13, 2015
-
-
Tony Tung authored
The bookmark state was already being preserved, but it wasn't being properly restored.
-
- Jan 27, 2015
-
-
Pierre-Yves David authored
Before this changeset rebase was getting very confused if any revision in the rebase set became hidden. This was fairly easy to achieve if a rebased revision was made visible by the working copy location. The rebase process would update somewhere else and the revision would become hidden. To work around this issue, we ensure rebased revisions remain visible for the whole process. This is a simple change suitable for stable. More subtle usage of unfiltered repository in rebase may solve this issue more cleanly.
-
- Jan 18, 2015
-
-
Wagner Bruna authored
-
- Jan 15, 2015
-
-
Angel Ezquerra authored
This change touches every module in which repository.opener was being used, and changes it for the equivalent repository.vfs. This is meant to make it easier to split the repository.vfs into several separate vfs. It should now be possible to remove localrepo.opener.
-
- Jan 04, 2015
-
-
Mads Kiilerich authored
The code for picking a merge ancestor when rebasing merges had a long and incorrect comment. The comment would perhaps have been fine as commit message but does not make the code more readable or maintainable and is a bad substitute for correct and readable code. The correct essense of the comment is quite trivial: a merge of an ancestor of the rebase destination and an 'outside' revision can be rebased as if it was a linear change, using 'destination ancestor parent' as base and pretty much ignoring the 'outside' revision. The code path where the comment is placed is however also used for other kinds of merge rebases. The comment is thus not really correct and not helpful. I think it would be better to drop the comment and rewrite the code.
-
- Oct 11, 2012
-
-
kiilerix authored
It deserves more than a debug message. Show a note like: updating mq patch p0.patch to 5:9ecc820b1737 The message could also refer to "qrefresh" instead. Same same.
-
- Dec 10, 2014
-
-
Mads Kiilerich authored
-
Mads Kiilerich authored
Similar to graft: note: rebase of 6:eea13746799a created no changes to commit
-
- Dec 09, 2014
-
-
Mads Kiilerich authored
Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
-
- Dec 02, 2014
-
-
Pierre-Yves David authored
Revtodo happens to share its value with nullrev, but this is an implementation details, so we move away from it. After this changeset one can successfully change the values for all the constants and the tests still pass, but doing so would require more refactoring if we want to avoid breaking backward compatibility on the state file.
-
Pierre-Yves David authored
The state mapping is using '-1' to mark revisions that have not been rebased yet. We introduce and use a constant for that purpose. This will help emphasize the fact the value means something other than nullrev.
-
- Dec 04, 2014
-
-
Pierre-Yves David authored
The fact that the state for "not yet rebased" is -1 is an implementation details. So we change the comparisons to some semantically more correct.
-
- Nov 19, 2014
-
-
Mads Kiilerich authored
We want to collect all calculation in one place.
-
- Dec 02, 2014
-
-
Mads Kiilerich authored
-
Mads Kiilerich authored
-
Mads Kiilerich authored
-
Matt Mackall authored
-
Pierre-Yves David authored
The state mapping also contains some magic negative values (detached parent, ignored revision). Blindly reading the state thus lead to unfortunate usage of the negative value as an update destination. We now filter them out. We do a minor alteration of the test to catch this.
-
- Nov 12, 2014
-
-
Matt Mackall authored
-