[Google SOC] Rebase command
peter.arrenbrecht at gmail.com
Wed Mar 26 05:47:27 CDT 2008
On Wed, Mar 26, 2008 at 11:27 AM, Stefano <stefano at inventati.org> wrote:
> during the process of making up my mind I wrote a very simple script
> whose aim is
> to ensure that I got the point. Please correct me if I'm wrong.
> I read a lot about it and there are several pros and cons in rebasing,
> but I think it's
> widely recognized as a killer-feature of git.
> The main problems lay when dealing with user interaction/interruption,
> that's why it's my
> intention (thank you Mezard for the hint) to start working on a
> non-interruptible version
> and eventually decide to improve it. (Note: git allows interaction in
> very interesting way)
> Now, I'm going to investigate how it could be done in Mercurial.
> Please don't hesitate to post any suggestion!
> Stefano Tortarolo
> echo "-- Initializing Master repository"
> hg init Master
> echo -e "\n-- User a clones, adds a file and pushes"
> hg clone Master user_a && cd user_a
> echo "testa1" > a_1; hg add a_1; hg commit -m "added file a_1" ; hg push
> echo -e "\n-- User b clones, adds a file without pushing"
> cd $BASEDIR
> hg clone Master user_b && cd user_b
> echo "testb1" > b_1; hg add b_1; hg commit -m "added file b_1"
> echo -e "\n-- User a adds a file and pushes"
> cd $BASEDIR/user_a
> echo "testa2" > a_2; hg add a_2; hg commit -m "added file a_2" ; hg push
> echo -e "\n-- Now user b pulls from Master"
> cd $BASEDIR/user_b
> hg pull ; hg heads
> # User b gets 2 heads and its commit is between id 0 and id 2
> # He never pushed on Master (he's working on a local repository for now)
> # so it would be great if he could put his commit on top of the revisions
> # doing something like:
> # hg rebase Master
> # currently he'll do a merge and the history will keep trace of it
> # hg merge
> cd $BASEDIR && rm -rf Master user_a user_b a_1 a_2 b_1
Basically yes, but:
1. It gets more interesting if both A and B work on the same file (a
suitable line distance apart) so three-way-merge will be needed.
2. The "transplant" case is more interesting, too, where A wants to
cherry-pick change Y from B's repo where B has new unpushed changes X,
More information about the Mercurial-devel