- Feb 04, 2016
-
-
timeless authored
Suggest committing (or whatever the current activity is), via wrongtooltocontinue which uses howtocontinue.
-
- Feb 08, 2016
-
-
Pierre-Yves David authored
As we will make 'rebase' behave more like 'merge', it will no longer pick 'max(branch(.))' as the default destination. We have to hard code the expected destination is multiple tests where it matters. After a careful inspection none of theses tests really cares about the default destination behavior and just omitted one out of laziness.
-
Pierre-Yves David authored
These tests do not care about that extra branch at all. In future changeset we will make rebase behave like merge and abort in case of an ambiguous destination (eg: multiple other heads) and that extra branch will make the command invocation breaks. We preventively remove this extra branch from the relevant tests in an independant changeset to reduce noise and increase confidence in the final change.
-
- Feb 01, 2016
-
-
Martijn Pieters authored
Rather than look for the lowest revision, see if the rebase state is tracking the parents of this revision. Otherwise we can't handle multiple revisions in one rebase that includes a merge revision. Fixes issue5044.
-
- Dec 24, 2015
-
-
timeless authored
-
- Oct 06, 2015
- 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
-
- May 29, 2015
-
-
Gilles Moris authored
The phase of the pending commit depends on the parent of the working directory and on the phases.newcommit configuration. First, this information rather depend on the commit line which describe the pending commit. Then, we only want to be advertised when the pending phase is going to be higher than the default new commit phase. So the format will change from $ hg summary parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) update: (current) phases: 1 secret (secret) to parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret) update: (current) phases: 1 secret
-
- May 14, 2015
-
-
Gilles Moris authored
The number of draft and secret changesets are currently not summarized. This is an important information because the number of drafts give some rough idea of the number of outgoing changesets in typical workflows, without needing to probe a remote repository. And a non-zero number of secrets means that those changeset will not be pushed. If the repository is "dirty" - some draft or secret changesets exists - then summary will display a line like: phases: X draft, Y secret (public) The phase in parenthesis corresponds to the highest phase of the parents of the working directory, i.e. the current phase. By default, the line is not printed if the repository is "clean" - all changesets are public - but if verbose is activated, it will display: phases: (public) On the other hand, nothing will be printed if quiet is in action. A few tests have been added in test-phases.t to cover the -v and -q cases.
-
- Jan 18, 2015
-
-
Wagner Bruna authored
-
- Jan 09, 2015
-
-
Durham Goode authored
Previously, a backup bundle could overwrite an existing bundle and cause user data loss. For instance, if you have A<-B<-C and strip B, it produces backup bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it overwrites the existing B-backup.hg and C is lost. The fix is to add a hash of all the nodes inside that bundle to the filename. Fixed up existing tests and added a new test in test-strip.t
-
- Dec 10, 2014
-
-
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 07, 2014
-
-
Mads Kiilerich authored
Globbing the hash made it harder to maintain tests with run-tests -i when it was so far by the generated test output. The hashes are stable and we just need to add a (glob).
-
- Nov 10, 2014
-
-
Durham Goode authored
The new rebase revset didn't check for the case when there are no common ancestors. Now it does. The new behavior should be the same as the pre-3.2 behavior. Added a test.
-
- Sep 01, 2014
-
-
David Soria Parra authored
A common mistake can be to type 'hg rebase -i' to discover interactive history editing. We add a -i/--interactive flag as discussed in the sprint and deprecate it right away, but hint people using it to use histedit instead.
-
- Jul 26, 2014
-
-
Pierre-Yves David authored
This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
-
- May 09, 2014
-
-
Matt Mackall authored
The recently introduced message was: no unresolved files; you may continue your unfinished operation This had three problems: - looks a bit like an error message because it's not saying "we've just resolved the last file" - refers to "unfinished operation", which won't be the case with "update" or "merge" - introduces semicolons to error messages, which is stylistically questionable I've simplified this to: no more unresolved files In the future, if we want to prompt someone to continue a particular operation, we should use a hint style: no more unresolved files (use 'hg graft --continue' to finish grafting)
-
- Apr 19, 2014
-
-
Gregory Szorc authored
When using resolve, users often have to consult with the output of |hg resolve -l| to see if any unresolved files remain. This step is tedious and adds overhead to resolving. This patch will notify a user if there are no unresolved files remaining after executing |hg resolve|:: no unresolved files; you may continue your unfinished operation The patch stops short of telling the user exactly what command should be executed to continue the unfinished operation. That is because this information is not currently captured anywhere. This would make a compelling follow-up feature.
-
- May 01, 2014
-
-
Mads Kiilerich authored
-
- Apr 23, 2014
-
-
Julien Cristau authored
The documentation says we exit 1 if we have nothing to do, so avoid breaking that contract when we're passed an empty revset. This was changed in http://www.selenic.com/hg/rev/a259f7b488ab to improve the error message; keep the improved message, just not the abort.
-
- Nov 17, 2013
-
-
Mads Kiilerich authored
Before it just said 'nothing to rebase'. Now 'if "base" is an empty set: abort: empty "base" revision set - can't compute rebase set If the set of changesets to rebase can't be found from "base", it will fail as before but with more explanation of what the problem was. The name of the "base" option is not obvious - it is more like "samples identifying the branch to rebase". The error messages for problems with the specified "base" value will use that term and might thus also not be obvious, but at least they are consistent with the option name. The name "base" will not be used if the base only was specified implicitly as the working directory parent.
-
Mads Kiilerich authored
Before, it just said 'nothing to rebase' in this case. Now, it aborts mentioning the reason: 'empty "source" revision set'. Specifying revisions that cannot be rebased is a 'soft' error, but specifying an empty set deserves an abort that explains exactly what the problem is.
-
- Nov 16, 2013
-
-
Mads Kiilerich authored
Before, it just said 'nothing to rebase' in this case. Now, it aborts mentioning the reason: 'empty "rev" revision set'. Specifying revisions that cannot be rebased is a 'soft' error, but specifying an empty set deserves an abort that explains exactly what the problem is.
-
- Nov 17, 2013
-
-
Mads Kiilerich authored
-
- Nov 22, 2013
-
-
Martin Geisler authored
Since graphlog is in core, we can use 'hg log -G' instead.
-
- Oct 14, 2013
-
-
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)
-
- May 14, 2013
-
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
-
- Feb 08, 2013
- Jun 20, 2012
-
-
Pierre-Yves David authored
Rebase now behaves as if --detach was always passed. Non-merges are rebased as non-merges, regardless of their parent being an ancestor of the destination. Merges will usually be rebased as merges unless both of their parents are ancestors of the destination, or one of their parents is pruned when rebased. This only alters the behavior of rebase when using the --source/--rev options. --detach option is deprecated. All test changes were carefully validated.
-
- Jun 10, 2012
-
-
kiilerix authored
Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
-
- May 01, 2012
-
-
Patrick Mézard authored
-
- Apr 29, 2012
-
-
Patrick Mézard authored
- --source and revset - --base and revset - --rev and revset - --rev and --source combination - --rev and --base combination
-
- Apr 03, 2012
-
-
Thomas Arendsen Hein authored
With this quoting tests will work e.g. in "/tmp/foo bar/mercurial/".
-
- Dec 26, 2011
-
-
Pierre-Yves David authored
-
- Oct 15, 2011
-
-
Pierre-Yves David authored
This option allow a strict set of revision to be specified instead of using -s or -b. Rebase will refuse start if striping rebased changeset will strip non rebased changeset. Rebase will refuse to work on set with multiple root.
-
Pierre-Yves David authored
The buildstate function now take a set of revs. Logic related to --source and --base option have been moved in the main rebase function. In the process this fixes a bug where the wrong source changeset might be pick. This explain the changes in hgext/rebase.py
-