[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