- Oct 26, 2015
-
-
Stanislau Hlebik authored
This parameter will allow us to set the date of rebased commits
-
- Oct 19, 2015
-
-
Mads Kiilerich authored
--collapse will do that rebase doesn't commit until the final commit. The lack of a new commit would make it look like the rebase didn't contribute any changes. Instead, only warn about no commits when not using --collapse.
-
- Oct 16, 2015
-
-
Mads Kiilerich authored
-
Katsunori FUJIWARA authored
Now, 'dirstate.write(tr)' delays writing in-memory changes out, if a transaction is running. This may cause treating this revision as "the first bad one" at bisecting in some cases using external hook process inside transaction scope, because some external hooks and editor process are still invoked without HG_PENDING and pending changes aren't visible to them. 'dirstate.write()' callers below in localrepo.py explicitly use 'None' as 'tr', because they can assume that no transaction is running: - just before starting transaction - at closing transaction, or - at unlocking wlock
-
- Oct 15, 2015
-
-
Christian Delahousse authored
Refactoring by reduce the scope of the try catch block so that it only captures what it needs. I could have made it smaller but another patch in the series will add onto it.
-
Christian Delahousse authored
When a user's repository is in an unfinished rebase state and they choose to abort, at a minimum, the repo should be out of that state. We've found situations where the user could not leave the state unless manually deleting the rebasestate file. This fix ensures that no matter what exception may be raised during the abort, the rebase state file will be deleted, the user will be out of the rebase state and they can get their repository into a workable condition.
-
Pierre-Yves David authored
We make the name consistent with the other similar revsets and make sure it has minimal tests.
-
Pierre-Yves David authored
There is little value in using the revset instead of the function.
-
Pierre-Yves David authored
This makes it much simple to wrap for other extension.
-
- Oct 13, 2015
-
-
Christian Delahousse authored
After rebasing a set of changes onto a public changeset and having the first one be skipped, if you try to abort, the operation fails. This fix adds a check to disallow the target rev into the dstates list within the abort function. This list is checked for immutable states before the rest of abort does its thing.
-
- Oct 14, 2015
-
-
Pierre-Yves David authored
As obsolescence markers can contains unknown nodes and 'allsuccessors' returns them, we have to protect again that when looking for successors of the rebase set in the destination. Test have been expanded to catch that.
-
Pierre-Yves David authored
Accessing 'repo.changelog' have a small overhead because we double check that the filtering did not changed. As we make multiple use of this into loops, we should avoid doing the lookup/check every time. This also make the code tidier.
-
- Oct 13, 2015
-
-
Ryan McElroy authored
A rebase call that results in nothing to rebase might be considered successful in some contexts. This factors out the return code from places where hg determines that there is nothing to rebase, so an extenion might change this return code to be something that would allow scripts to run without seeing this as an error.
-
Christian Delahousse authored
Added comments describing the state variable and constants used throughout the rebase extension
-
- Oct 08, 2015
-
-
Pierre-Yves David authored
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be confused about that and gives all the credit to 'util' instead of the hardworking 'error'. In a spirit of equity, we break the cycle of injustice and give back to 'error' the respect it deserves. And screw that 'util' poser. For great justice.
-
- Oct 06, 2015
- 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.
-