[PATCH 2 of 2] pull: new output message suggests better update action when a new branch head is added
Kevin Bullock
kbullock+mercurial at ringworld.org
Wed Mar 16 17:55:27 CDT 2011
On Mar 15, 2011, at 10:42 PM, Matt Mackall wrote:
> This is about where it becomes useful to enumerate all possible outcomes
> in a table.
>
> current named branch
> no new heads new heads
> overall
> no new heads update [1]
> new heads [2] [3]
> new branches [4] [5]
>
> What messages should we get for 1, 2, and 3? I suspect 1 == 3, but we
> probably want a different non-empty message for 2. Not sure about 4 and
> 5.
If I might suggest a slightly more useful table (which might be what you meant anyway, but this clarifies at least case [3]):
current named branch
no new heads new heads
other named branches
no new heads [0] [1]
new heads [2] [3]
new branches [4] [5]
then what the patch gives us as it stands is:
0: nothing (modheads == 0), or "run 'hg update' to get a working copy"
1: "run 'hg heads' to see heads, 'hg merge' to merge"
2: "new branch heads added, run 'hg update [new branch]' to get a working copy"
3: same as [1]
4: same as [2]
5: same as [1]
Here are my suggestions:
0: keep as is
1: "run 'hg heads .' to see heads, 'hg merge' to merge" (per Greg's suggestion)
2: "new heads added on OTHERBRANCH" or just "new heads added on another branch"
3: "run 'hg heads .' or 'hg heads BRANCH' to see branch heads, 'hg merge' to merge"
4: "run 'hg branches' to see branches", and list e.g. "(+1 heads, +1 branches)"
5: same as [1]
though I'm not settled on [2] or [3]. We risk getting too verbose if we try to suggest what to do with the _other_ branch, but giving no guidance seems wrong.
pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock
More information about the Mercurial-devel
mailing list