Some way of preventing "hg update" without arguments?

[Andrew Fischer]

That sounds perfect; a simple alias never occurred to me.Thanks for the
help!

-Andrew

On Fri, Apr 1, 2016 at 11:35 AM, Arnel <rcl at openmailbox.org> wrote:

> On Fri, 1 Apr 2016 10:42:27 -0500, Andrew Fischer <andrew at apastron.co>
> wrote:
> > We have a project with a workflow that uses bookmarks and multiple heads
> on
> > the default branch for small feature development. I've had to bring
> several
> > people up to speed who are not familiar with mercurial, and one problem
> > keeps eating up my time:
> >
> > They pull new code and simply call "hg update". Which of course updates
> to
> > tip and advances whatever bookmark they currently have active to that
> tip.
> > Just as expected. But then I get a message because their bookmark is no
> > longer on the local head they were working on and instead at tip. And
> what
> > to do, etc. etc. I always have to explain "don't just 'hg update' after a
> > pull. Look at what is new and update to the bookmark you want to use".
> >
> > I was wondering, is there some way I can use the .hgrc to simply not
> allow
> > a bare "hg update" command with no arguments? It feels like it would be a
> > quick short-term way to get people used to not simply updating to tip
> right
> > away when they pull, forcing them to "hg update tip" if that really is
> > desired or instead "hg update bookmarkYouReallyWant". I suppose this
> means
> > I would have to stop "hg pull -u" as well.
>
> You could probably set an alias in their .hgrc like so:
>
> [alias]
> update = update -r .
>
> That should make them stay at their current revision and not move the
> bookmark.
>
> --Arnel
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>



-- 
Andrew Fischer, PhD
Apastron, Co
903 1st ST N Hopkins, MN
952-373-1024
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160401/880a26cc/attachment-0002.html>