- Oct 30, 2013
-
-
Pierre-Yves David authored
Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
-
- Oct 23, 2013
-
-
Mads Kiilerich authored
-
- Oct 24, 2013
-
-
Mads Kiilerich authored
-
- Oct 23, 2013
-
-
Mads Kiilerich authored
-
- Oct 14, 2013
-
-
Pierre-Yves David authored
Now that the working directory parent is preserved, we can preserve the active bookmark too.
-
Pierre-Yves David authored
Prior to this changeset, rebase always left the working directory as a parent of the last rebased changeset. The is dubious when, before the rebase, the working directory was not a parent of the tip most rebased changeset. With this changeset, we move the working directory back to its original parent. If the original parent was rebased, we use it's successors. This is a step toward solving issue3813 (rebase loses active bookmark if it's not on a head)
-
- Oct 01, 2013
- Oct 02, 2013
-
-
Matt Mackall authored
-
- Sep 30, 2013
-
-
Katsunori FUJIWARA authored
Before this patch, "hg summary" may fail, when there is inconsistent rebase state: for example, the root of rebase destination revisions recorded in rebase state file is already stripped manually. Mercurial earlier than 2.7 allows users to do anything other than starting new rebase, even though current rebase is not finished or aborted yet. So, such inconsistent rebase states may be left and forgotten in repositories. This patch catches RepoLookupError at restoring rebase state for summary hook, and treat such state as "broken".
-
Katsunori FUJIWARA authored
Before this patch, "rebase --abort"/"--continue" may fail, when rebase state is inconsistent: for example, the root of rebase destination revisions recorded in rebase state file is already stripped manually. Mercurial earlier than 2.7 allows users to do anything other than starting new rebase, even though current rebase is not finished or aborted yet. So, such inconsistent rebase states may be left and forgotten in repositories. This patch catches RepoLookupError at restoring rebase state for abort/continue, and treat such state as "broken".
-
- Sep 20, 2013
-
-
Siddharth Agarwal authored
This saves us a relatively superfluous status check for pull --rebase (if rebase runs, it'll check for a clean working directory anyway), and brings hg pull --rebase closer to hg pull && hg rebase. This is a behavior change because pull --rebase with a dirty working directory will now abort after performing the pull rather than before.
-
- Sep 03, 2013
-
-
Bryan O'Sullivan authored
We handled these correctly with all rev-specifying options except, somehow, -r/--rev.
-
Bryan O'Sullivan authored
We handled these correctly with all rev-specifying options except, somehow, -r/--rev.
-
- Aug 01, 2013
-
-
Matt Mackall authored
With this, all aborts will succeed in removing the state, rather than leaving the user in 'what do I do now?' limbo.
-
Matt Mackall authored
This causes us to simply discard the rebase state.
-
Matt Mackall authored
-
- Jul 25, 2013
-
-
Matt Mackall authored
Turns out histedit actually intends for commits (but not other operations like update) to be possible during its operation.
-
Matt Mackall authored
-
Matt Mackall authored
This could cause a rebase to be 'in progress' even though it aborted.
-
- Jul 12, 2013
-
-
Matt Mackall authored
-
- May 14, 2013
-
-
Bryan O'Sullivan authored
-
- Apr 18, 2013
-
-
Siddharth Agarwal authored
This could lead to user confusion, because phases aren't really involved at all when attempting to perform a no-op rebase.
-
- Feb 08, 2013
-
-
durin42 authored
-
- Mar 12, 2013
-
-
Bryan O'Sullivan authored
-
- Mar 11, 2013
-
-
Durham Goode authored
When a rebase has conflicts and the user uses rebase --continue, the previously active bookmark was not being made active once again. With this change that bookmark is made active again, just as if the rebase had never been interrupted. This changes the rebasestate file format, but should handle old formats correctly. Since the file is transient, this is even less of a problem. Adds a test to verify the new behavior. I manually tested continuing rebases with and without an active bookmark, and with and without being on the bookmark being rebased.
-
- Feb 10, 2013
-
-
kiilerix authored
-
- Feb 03, 2013
-
-
Siddharth Agarwal authored
dest.rev() is the same as target when a new rebase is run, but dest isn't set when rebase --continue is run. Bug introduced in 2a1fac3650a5, which fixed issue3685.
-
- Feb 01, 2013
-
-
Pierre-Yves David authored
This changeset adds a small mention of it in the help to prevent confusion. This small addition references online help that is easier to update and improve at release time. Following Wagner Bruna's advice, this is added in a plain new paragraph to not invalidate current translation this close to the release.
-
Kevin Bullock authored
Mention that Mercurial helps you not do what you've just been warned not to do, with a reference to the 'phases' help topic (not the 'phase' command help). Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for motivating this change and Wagner Bruna <wagner.bruna+mercurial@gmail.com> for advising on how to do it in an i18n-friendly way.
-
- Jan 31, 2013
-
-
Siddharth Agarwal authored
Similar to merge, divergent bookmarks are only deleted when the bookmark is on the destination parent.
-
Siddharth Agarwal authored
nstate[v] is a node, not an int, and the nullmerge check was done while building nstate anyway.
-
- Jan 18, 2013
-
-
Pierre-Yves David authored
With rebase taking multiple roots it is possible to have revision in the "rebase domain" not rebased themself. We do not want rebased revision above them to be detached. We want such revision to be rebased on the nearest rebased ancestors. This allows to preserve the topology of the rebase set as much a possible To achieve this we introduce a new state `revignored` which informs `defineparents` of the situation. The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.
-
Pierre-Yves David authored
For a proper behavior of the `--rev` revision we will need another possible state for revision ignored by rebase. We alter the comparison to `nullmerge` to match this future lower state too.
-
Pierre-Yves David authored
When rebase results in an empty a changeset it is "skipped" and no related changeset is created at all. When we added obsolescence support to rebase (in fc2a6114f0a0) it seemed a good idea to use its parent successor as the successors for such dropped changesets. (see old version of the altered test). This option was chosen because it seems a good way to hint about were the dropped changeset "intended" to be. Such hint would have been used by automatic evolution mechanism to rebase potential unstable children. However, field testing of this version are not conclusive. It very often leads to the creation of (totally unfounded) evolution divergence. This changeset changes this behavior and mark skipped changesets as pruned (obsolete without successors). This prevents the issue and seems semantically better probably a win for obsolescence reading tool. See example bellow for details: User Babar has five changesets of interest: - O, its current base of development. - U, the new upstream - A and C, some development changesets - B another development changeset independent from A O - A - B - C \ U Babar decides that B is more critical than the A and C and rebase it first $ hg rebase --rev B --dest U B is now obsolete (in lower case bellow). Rebase result, B', is its successors.(note, C is unstable) O - A - b - C \ U - B' Babar is now done with B', and want to rebase the rest of its history: $ hg rebase --source A --dest B' hg rebase process A, B and C. B is skipped as all its changes are already contained in B'. O - U - B' - A' - C' Babar have the expected result graph wise, obsolescence marker are as follow: B -> B' (from first rebase) A -> A' (from second rebase) C -> C' (from second rebase) B -> ?? (from second rebase) Before this changeset, the last marker is `B -> A'`. This cause two issues: - This is semantically wrong. B have nothing to do with A' - B has now two successors sets: (B',) and (A',). We detect a divergent rewriting. The B' and A' are reported as "divergent" to Babar, confusion ensues. In addition such divergent situation (divergent changeset are children to each other) is tricky to solve. With this changeset the last marker is `B -> ø`: - This is semantically better. - B has a single successors set (B',) This scenario is added to the tests suite.
-
- Jan 16, 2013
-
-
Pierre-Yves David authored
We have all the necessary mechanism to rebase a set with multiple roots, we only needed a proper handling of this case we preparing and concluding the rebase. This changeset des that. Rebase set with multiple root allows some awesome usage of rebase like: - rebase all your draft on lastest upstream hg rebase --dest @ --rev 'draft()' - exclusion of specific changeset during rebase hg rebase --rev '42:: - author(Babar)' - rebase a set of revision were multiple roots are later merged hg rebase --rev '(18+42)::'
-
- Jan 15, 2013
-
-
Mads Kiilerich authored
-
- Dec 04, 2012
-
-
Pierre-Yves David authored
Hidden changeset filtering is now done at repo level. The rebaseset computation will not include any (unless you add --hidden).
-
- Dec 31, 2012
-
-
Pierre-Yves David authored
Obsolescence markers can represent this situation just fine. Rebased revisions are marked as precursors of the ones create by rebase. Unrebased descendants becomes "unstable". If obsolescence is not enabled we keep the current behavior of aborting. This new behavior only applies when obsolete is enabled and is subject to future discussion and changes.
-
- Dec 18, 2012
-
-
Siddharth Agarwal authored
For a repository with over 400,000 commits, rebasing one revision near tip, this avoids one walk up the DAG, speeding the operation up by around 0.8 seconds.
-