##// END OF EJS Templates
rebase: add error codes...
rebase: add error codes Suggested by Dirk Hasselbalch

File last commit:

r11205:d26f662b default
r11205:d26f662b default
Show More
test-rebase-parameters.out
304 lines | 13.8 KiB | text/plain | TextLexer
/ tests / test-rebase-parameters.out
% These fail
% Use continue and abort
hg rebase: cannot use both abort and continue
hg rebase [-s REV | -b REV] [-d REV] [options]
hg rebase {-a|-c}
move changeset (and descendants) to a different branch
Rebase uses repeated merging to graft changesets from one part of history
(the source) onto another (the destination). This can be useful for
linearizing *local* changes relative to a master development tree.
You should not rebase changesets that have already been shared with
others. Doing so will force everybody else to perform the same rebase or
they will end up with duplicated changesets after pulling in your rebased
changesets.
If you don't specify a destination changeset ("-d/--dest"), rebase uses
the tipmost head of the current named branch as the destination. (The
destination changeset is not modified by rebasing, but new changesets are
added as its descendants.)
You can specify which changesets to rebase in two ways: as a "source"
changeset or as a "base" changeset. Both are shorthand for a topologically
related set of changesets (the "source branch"). If you specify source
("-s/--source"), rebase will rebase that changeset and all of its
descendants onto dest. If you specify base ("-b/--base"), rebase will
select ancestors of base back to but not including the common ancestor
with dest. Thus, "-b" is less precise but more convenient than "-s": you
can specify any changeset in the source branch, and rebase will select the
whole branch. If you specify neither "-s" nor "-b", rebase uses the parent
of the working directory as the base.
By default, rebase recreates the changesets in the source branch as
descendants of dest and then destroys the originals. Use "--keep" to
preserve the original source changesets. Some changesets in the source
branch (e.g. merges from the destination branch) may be dropped if they no
longer contribute any change.
One result of the rules for selecting the destination changeset and source
branch is that, unlike "merge", rebase will do nothing if you are at the
latest (tipmost) head of a named branch with two heads. You need to
explicitly specify source and/or destination (or "update" to the other
head, if it's the head of the intended source branch).
If a rebase is interrupted to manually resolve a merge, it can be
continued with --continue/-c or aborted with --abort/-a.
Returns 0 on success, 1 if nothing to rebase.
options:
-s --source rebase from the specified changeset
-b --base rebase from the base of the specified changeset (up to
greatest common ancestor of base and dest)
-d --dest rebase onto the specified changeset
--collapse collapse the rebased changesets
--keep keep original changesets
--keepbranches keep original branch names
--detach force detaching of source from its original branch
-c --continue continue an interrupted rebase
-a --abort abort an interrupted rebase
--style display using template map file
--template display with template
use "hg -v help rebase" to show global options
% Use continue and collapse
hg rebase: cannot use collapse with continue or abort
hg rebase [-s REV | -b REV] [-d REV] [options]
hg rebase {-a|-c}
move changeset (and descendants) to a different branch
Rebase uses repeated merging to graft changesets from one part of history
(the source) onto another (the destination). This can be useful for
linearizing *local* changes relative to a master development tree.
You should not rebase changesets that have already been shared with
others. Doing so will force everybody else to perform the same rebase or
they will end up with duplicated changesets after pulling in your rebased
changesets.
If you don't specify a destination changeset ("-d/--dest"), rebase uses
the tipmost head of the current named branch as the destination. (The
destination changeset is not modified by rebasing, but new changesets are
added as its descendants.)
You can specify which changesets to rebase in two ways: as a "source"
changeset or as a "base" changeset. Both are shorthand for a topologically
related set of changesets (the "source branch"). If you specify source
("-s/--source"), rebase will rebase that changeset and all of its
descendants onto dest. If you specify base ("-b/--base"), rebase will
select ancestors of base back to but not including the common ancestor
with dest. Thus, "-b" is less precise but more convenient than "-s": you
can specify any changeset in the source branch, and rebase will select the
whole branch. If you specify neither "-s" nor "-b", rebase uses the parent
of the working directory as the base.
By default, rebase recreates the changesets in the source branch as
descendants of dest and then destroys the originals. Use "--keep" to
preserve the original source changesets. Some changesets in the source
branch (e.g. merges from the destination branch) may be dropped if they no
longer contribute any change.
One result of the rules for selecting the destination changeset and source
branch is that, unlike "merge", rebase will do nothing if you are at the
latest (tipmost) head of a named branch with two heads. You need to
explicitly specify source and/or destination (or "update" to the other
head, if it's the head of the intended source branch).
If a rebase is interrupted to manually resolve a merge, it can be
continued with --continue/-c or aborted with --abort/-a.
Returns 0 on success, 1 if nothing to rebase.
options:
-s --source rebase from the specified changeset
-b --base rebase from the base of the specified changeset (up to
greatest common ancestor of base and dest)
-d --dest rebase onto the specified changeset
--collapse collapse the rebased changesets
--keep keep original changesets
--keepbranches keep original branch names
--detach force detaching of source from its original branch
-c --continue continue an interrupted rebase
-a --abort abort an interrupted rebase
--style display using template map file
--template display with template
use "hg -v help rebase" to show global options
% Use continue/abort and dest/source
hg rebase: abort and continue do not allow specifying revisions
hg rebase [-s REV | -b REV] [-d REV] [options]
hg rebase {-a|-c}
move changeset (and descendants) to a different branch
Rebase uses repeated merging to graft changesets from one part of history
(the source) onto another (the destination). This can be useful for
linearizing *local* changes relative to a master development tree.
You should not rebase changesets that have already been shared with
others. Doing so will force everybody else to perform the same rebase or
they will end up with duplicated changesets after pulling in your rebased
changesets.
If you don't specify a destination changeset ("-d/--dest"), rebase uses
the tipmost head of the current named branch as the destination. (The
destination changeset is not modified by rebasing, but new changesets are
added as its descendants.)
You can specify which changesets to rebase in two ways: as a "source"
changeset or as a "base" changeset. Both are shorthand for a topologically
related set of changesets (the "source branch"). If you specify source
("-s/--source"), rebase will rebase that changeset and all of its
descendants onto dest. If you specify base ("-b/--base"), rebase will
select ancestors of base back to but not including the common ancestor
with dest. Thus, "-b" is less precise but more convenient than "-s": you
can specify any changeset in the source branch, and rebase will select the
whole branch. If you specify neither "-s" nor "-b", rebase uses the parent
of the working directory as the base.
By default, rebase recreates the changesets in the source branch as
descendants of dest and then destroys the originals. Use "--keep" to
preserve the original source changesets. Some changesets in the source
branch (e.g. merges from the destination branch) may be dropped if they no
longer contribute any change.
One result of the rules for selecting the destination changeset and source
branch is that, unlike "merge", rebase will do nothing if you are at the
latest (tipmost) head of a named branch with two heads. You need to
explicitly specify source and/or destination (or "update" to the other
head, if it's the head of the intended source branch).
If a rebase is interrupted to manually resolve a merge, it can be
continued with --continue/-c or aborted with --abort/-a.
Returns 0 on success, 1 if nothing to rebase.
options:
-s --source rebase from the specified changeset
-b --base rebase from the base of the specified changeset (up to
greatest common ancestor of base and dest)
-d --dest rebase onto the specified changeset
--collapse collapse the rebased changesets
--keep keep original changesets
--keepbranches keep original branch names
--detach force detaching of source from its original branch
-c --continue continue an interrupted rebase
-a --abort abort an interrupted rebase
--style display using template map file
--template display with template
use "hg -v help rebase" to show global options
% Use source and base
hg rebase: cannot specify both a revision and a base
hg rebase [-s REV | -b REV] [-d REV] [options]
hg rebase {-a|-c}
move changeset (and descendants) to a different branch
Rebase uses repeated merging to graft changesets from one part of history
(the source) onto another (the destination). This can be useful for
linearizing *local* changes relative to a master development tree.
You should not rebase changesets that have already been shared with
others. Doing so will force everybody else to perform the same rebase or
they will end up with duplicated changesets after pulling in your rebased
changesets.
If you don't specify a destination changeset ("-d/--dest"), rebase uses
the tipmost head of the current named branch as the destination. (The
destination changeset is not modified by rebasing, but new changesets are
added as its descendants.)
You can specify which changesets to rebase in two ways: as a "source"
changeset or as a "base" changeset. Both are shorthand for a topologically
related set of changesets (the "source branch"). If you specify source
("-s/--source"), rebase will rebase that changeset and all of its
descendants onto dest. If you specify base ("-b/--base"), rebase will
select ancestors of base back to but not including the common ancestor
with dest. Thus, "-b" is less precise but more convenient than "-s": you
can specify any changeset in the source branch, and rebase will select the
whole branch. If you specify neither "-s" nor "-b", rebase uses the parent
of the working directory as the base.
By default, rebase recreates the changesets in the source branch as
descendants of dest and then destroys the originals. Use "--keep" to
preserve the original source changesets. Some changesets in the source
branch (e.g. merges from the destination branch) may be dropped if they no
longer contribute any change.
One result of the rules for selecting the destination changeset and source
branch is that, unlike "merge", rebase will do nothing if you are at the
latest (tipmost) head of a named branch with two heads. You need to
explicitly specify source and/or destination (or "update" to the other
head, if it's the head of the intended source branch).
If a rebase is interrupted to manually resolve a merge, it can be
continued with --continue/-c or aborted with --abort/-a.
Returns 0 on success, 1 if nothing to rebase.
options:
-s --source rebase from the specified changeset
-b --base rebase from the base of the specified changeset (up to
greatest common ancestor of base and dest)
-d --dest rebase onto the specified changeset
--collapse collapse the rebased changesets
--keep keep original changesets
--keepbranches keep original branch names
--detach force detaching of source from its original branch
-c --continue continue an interrupted rebase
-a --abort abort an interrupted rebase
--style display using template map file
--template display with template
use "hg -v help rebase" to show global options
% Rebase with no arguments - from current
nothing to rebase
% Rebase with no arguments - from the current branch
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
nothing to rebase
% ----------
% These work
% Rebase with no arguments (from 3 onto 7)
3 files updated, 0 files merged, 2 files removed, 0 files unresolved
saved backup bundle to
% Try to rollback after a rebase (fail)
no rollback information available
% Rebase with base == '.' => same as no arguments (from 3 onto 7)
3 files updated, 0 files merged, 3 files removed, 0 files unresolved
saved backup bundle to
% Rebase with dest == default => same as no arguments (from 3 onto 7)
3 files updated, 0 files merged, 3 files removed, 0 files unresolved
saved backup bundle to
% Specify only source (from 4 onto 7)
saved backup bundle to
% Specify only dest (from 3 onto 6)
3 files updated, 0 files merged, 3 files removed, 0 files unresolved
saved backup bundle to
% Specify only base (from 3 onto 7)
saved backup bundle to
% Specify source and dest (from 4 onto 6)
saved backup bundle to
% Specify base and dest (from 3 onto 6)
saved backup bundle to