Note:

This page is primarily intended for developers of Mercurial.

Default destination plan

A lot of Mercurial command as "default" behavior, some needs revisiting.

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.

(<!>, 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"

1.1.4. Producer 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"

1.2. Analysis

  1. hg update moving to branch head: is a sensible default. Named branch denote a meaningful context/target/topic/product and hg update getting the most up-to-date content for that context.

  2. complains about non-linear: one of the interresting side effect of the complains about non-linear update is that in the common very basic operation, it help the user to spot that three is multiple heads and that something is to be done. However, the message are very bad at pointing this and there is a significant number of cases were this won't point it out.

  3. ignoring other lower heads: hg update while on max(branch(.)) will simply says "nothing to update" ignoring all the other unmerged heads on the branch.

  4. behavior change with --clean: The behavior change (allowing non linear update) seems very debatable. While the initial motivation is probably that merging uncommitted change from on head to another was technically impossible in early ages, this fit badly in the logical framework for point (1) and (2). It also make the command less consistent.

1.3. Behavior Change Proposal

There is multiple tier of change we use to improve the situation:

1. {x} Improving not a linear update message to mention heads and merge (waiting to be implemented).

2. (./) Adding warning message to update that end on a head when there is other heads on the branch.

3. (./) Having update destination become max(branch(.) and .::) as warning added in (2) provide the same usefulness as the non-linear abort.

4. Abort is there there is more than one possible destination heads (probably too radical)[REJECTED]

2. Default Rebase Destination

(we discuss the case without bookmark)

2.1. Current Behavior

Current default value for update is: max(branch(.))

2.1.1. Optimal case: pull things and rebase

#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 rebase move current local branch on newly pulled changesets

2.1.2. Optimal case: pull things, commit and rebase

#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 user commit his changes

#4 hg rebase says "nothing to rebase"

(Latest commit in the branch in working directory parent and default target.)

2.1.3. Optimal case: pulling multiple heads and rebase

#1 User is on branch foo, with some own local changesets on branch foo

#2 hg pull bring multiple heads in branch foo,

The pull commend mention that a new head is created.

#3 hg rebase silently pick a branch as destination.

2.2. Analysis

Rebase default destination is likely as it is to prevent possible issue with rebasing "public" changeset (from the pre-phases era). As it is:

However we now have phase, that prevent user to rebase bad things

The current destination has some obvious issues:

3. Merge behavior

3.1. Changes Proposal

Rebase semantic is very similar to merge semantic. We could and should share the same logic for default destination:

4. Progress

((./) done, <!> in progress, {X} Need to be done)


CategoryDeveloper and CategoryNewFeatures

DefaultDestinationPlan (last edited 2016-02-24 16:27:36 by Pierre-YvesDavid)