Problems with "pull --update"

[Steve Borho]

On Tue, Jan 5, 2010 at 12:50 PM, Greg Ward <greg at gerg.ca> wrote:
> I have discovered two problems with "pull --update": one quite
> trivial, one possibly deeper.
>
> 1) I'm pretty sure the help is incorrect: it says
>      update to new tip if changesets were pulled
>    but shouldn't that be
>      update to new branch head if changesets were pulled
>   ?  Someone tell me I'm wrong, or I'll send a patch.  ;-)
>
> 2) If you're expecting the same behaviour as "hg pull && hg update",
> you're in for a surprise.
>    At least this is clearly documented, but it means that users
> coming from CVS or Subversion
>    cannot use "hg pull -u" to replace "cvs up" or "svn up".  In the
> general case, you have to
>    "hg pull ; hg update".  ;-(
>
> #2 only occurred to me because I am documenting our new workflow
> (we're moving from CVS), and to make things less painful, I was going
> to try to promote "hg pull -u" as the replacement for "cvs update": do
> it before you start working on a patch, and then again before you
> commit.  But it only works as long as you're already at a branch head.
>  If you happen to be at an older changeset and nothing gets pulled,
> then you start working at the wrong place.  ;-(  So it sounds like I
> have to document "hg pull && hg update" as the replacement for "cvs
> update".
>
> If I had a time machine, I would just go back and change it so "hg
> pull --update" did the same as "pull && update", i.e. update
> regardless of whether anything was pulled.  But I guess that's against
> the compatibility rules.  Darn.  Anyone else annoyed by this?

We could add a new argument like 'hg pull -U', which would probably
confuse people wrt clone -U, but you get the idea.

--
Steve Borho