|
⇤ ← Revision 1 as of 2015-10-22 16:53:56
Size: 546
Comment:
|
Size: 4012
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| = Desfault destination plan = | = Default destination plan = A lot of Mercurial command as "default" behavior, some needs revisiting. |
| Line 9: | Line 11: |
| == Default Update Destination == (we discuss the case without bookmark) === Current Behavior === Current default value for update is: `max(branch(.))` ==== Pure Consumer Case ==== If the user is just using `hg pull` and `hg update` this work fine. #1 User is on branch `foo`, {{{#!dot digraph { rankdir=LR node [shape=box] A -> B; B [label="@B"]; } }}} #2 `hg pull` bring new changeset in branch `foo`, {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> C -> D; B [label="@B"]; } }}} #3 `hg update` bring the user on the latest (just pulled) changeset on `foo`. {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> C -> D; D [label="@D"]; } }}} ==== Consumer Case: pulling multiple heads ==== #1 User is on branch `foo`, {{{#!dot digraph { rankdir=LR node [shape=box] A -> B; B [label="@B"]; } }}} #2 `hg pull` bring multiple heads in branch `foo`, {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> C -> D; B -> X -> Y; B [label="@B"]; } }}} #3 `hg update` bring the user one of the head. {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> C -> D; B -> X -> Y; D [label="@D"]; } }}} * {X} user got only half of the pulled changesets * <!> used head is "arbitrary" * {X} No warning about the user heads (<!>, pulling multiple heads on a branch point at FeatureBranchesStruggle or advanced usecase/users) ==== Producer Case: simple ==== #1 User is on branch `foo`, with some own local changesets on branch `foo` {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> X -> Y; Y [label="@Y"]; } }}} #2 `hg pull` bring new changeset in branch `foo`, The pull commend mention that a new head is created. {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> X -> Y; B -> C -> D; Y [label="@Y"]; } }}} #3 `hg update` refuse to update for "non-linear update" * (./) This prompt the use toward doing a merge * <!> The message is not quite explicit about that * {X} Message is not issued if Y is created after the pull (quite common, if pulling with uncommitted change) * {X} `hg update --clean` will happily move to `D` without any message ==== Productor Case: pulling multiple heads ==== #1 User is on branch `foo`, with some own local changesets on branch `foo` {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> X; X [label="@X"]; } }}} #2 `hg pull` bring new changeset on the same topological branch and another new heads, (could also be achieved with use have X, Y locally but went back on X for some reason before the pull) The pull commend mention that a new head is created. {{{#!dot digraph { rankdir=LR node [shape=box] A -> B -> X -> Y; B -> C -> D; X [label="@X"]; } }}} #3 `hg update` refuse to update for "non-linear update" * (./) This prompt the use toward doing a merge * <!> The message is not quite explicit about that a merge * {X} Merging will not reduce the number of heads becase we are not a head * {X} `hg update --clean` will happily move to `D` without any message, actually 'updating backward' our current working copy. * {X} if Y existed before the pull, `hg up` would have brought us on Y. == Default Rebase Destination == |
|
| Line 11: | Line 193: |
| * (./) done * <!> in progress * {X} Need to be done |
((./) done, <!> in progress, {X} Need to be done) |
| Line 18: | Line 198: |
| * {X} fix default update destination, * {X} fix default rebase destination, == Default Update Destination == == Default Rebase Destination == |
* {X} rework default update destination, * {X} rework default rebase destination, * {X} rework default merge destination, |
Note:
This page is primarily intended for developers of Mercurial.
Default destination plan
A lot of Mercurial command as "default" behavior, some needs revisiting.
Contents
1. Default Update Destination
(we discuss the case without bookmark)
1.1. Current Behavior
Current default value for update is: max(branch(.))
1.1.1. Pure Consumer Case
If the user is just using hg pull and hg update this work fine.
#1 User is on branch foo,
#2 hg pull bring new changeset in branch foo,
#3 hg update bring the user on the latest (just pulled) changeset on foo.
1.1.2. Consumer Case: pulling multiple heads
#1 User is on branch foo,
#2 hg pull bring multiple heads in branch foo,
#3 hg update bring the user one of the head.
user got only half of the pulled changesets 
used head is "arbitrary" - No warning about the user heads
(<!>, pulling multiple heads on a branch point at FeatureBranchesStruggle or advanced usecase/users)
1.1.3. Producer Case: simple
#1 User is on branch foo, with some own local changesets on branch foo
#2 hg pull bring new changeset in branch foo,
The pull commend mention that a new head is created.
#3 hg update refuse to update for "non-linear update"
This prompt the use toward doing a merge - The message is not quite explicit about that
- Message is not issued if Y is created after the pull (quite common, if pulling with uncommitted change)
- hg update --clean will happily move to D without any message
1.1.4. Productor Case: pulling multiple heads
#1 User is on branch foo, with some own local changesets on branch foo
#2 hg pull bring new changeset on the same topological branch and another new heads,
(could also be achieved with use have X, Y locally but went back on X for some reason before the pull)
The pull commend mention that a new head is created.
#3 hg update refuse to update for "non-linear update"
- This prompt the use toward doing a merge
- The message is not quite explicit about that a merge
- Merging will not reduce the number of heads becase we are not a head
- hg update --clean will happily move to D without any message, actually 'updating backward' our current working copy.
- if Y existed before the pull, hg up would have brought us on Y.
2. Default Rebase Destination
3. Progress
((./) done, in progress, Need to be done)
- extra default destinations into their own functions,
- make the report/failure logic optional,
- expose default destination as revsets,
- rework default update destination,
- rework default rebase destination,
- rework default merge destination,