script suggestions

[Giorgos Keramidas]

On Sat, 23 Jan 2010 17:27:03 +1300, mp3geek <mp3geek at gmail.com> wrote:
> Seems if I use hg pull --rebase, I still have to do hg pull to
> actually pull any new changes

Not really, no.  You shouldn't need multiple pulls for rebase to work --
unless, of course, someone else pushes *more* changes between the time
of your first pull and your second pull.

I often rebase my work at the repositories of my dayjob, and all it
takes to really keep the changes on top of the latest tip (whatever that
happens to be) is to run:

    $ hg pull --rebase remote
    [ rebase and merge my local stuff ]
    $ hg push

If the "hg push" command reports that it would create a new head I just
lost a race.  Someone else has pushed more changes to the 'remote' tree,
so I re-rebase:

    $ hg pull --rebase remote
    $ hg push

Fortunately, we are a small team and there tend to be a really small
number of races between a pull-and-rebase step and a subsequent push.

> anyways, the script sort of works..
>
> #!/bin/bash
> hg pull --rebase
> hg add .
> hg update
> hg pull
> hg update
> hg commit -m "$1"
> hg push
>
> user at home-desktop:~$ ./script.sh "sample commit"
>
> However I've come accross when I tried to commit a new change, to then
> reverse another users commit, which I'd like to avoid happening.

This is often a local merge problem.  It is one of the reasons why I
usually recommend running a smart 3-way merge tools (like ediff-mode of
Emacs, vimdiff or kdiff3, meld, etc) and *carefully* looking at _all_
the rebased changesets before pushing back.