rebase-test

Samuel Ytterbrink

unread,

Nov 5, 2011, 6:51:40 AM11/5/11

to pytd...@googlegroups.com

Hi i tried to do a little test, it was really hard. since the rebase on hg vas very different from git, especially the default behavior.

But even with a lot of care it doesn't fit my modle. Somewhere it seams as if it actually doesn't just moves the changes? Also it seams as if a lot more commands are needed( you need to commit when making a branch or it will get removed when you move to another branch.)

For being written in python its not very pythonic at least for me hg gets in my way a lot!

malus:~ neppord$ mkdir rebase-test

malus:~ neppord$ cd rebase-test/

malus:rebase-test neppord$ hg init

malus:rebase-test neppord$ echo "Initial data" > FILE

malus:rebase-test neppord$ hg addremove

lägger till FILE

malus:rebase-test neppord$ hg commit -m "initial commit"

malus:rebase-test neppord$ hg branch developer

markerade arbetskatalogen som grenen developer

malus:rebase-test neppord$ echo "some developed code" >> FILE

malus:rebase-test neppord$ hg commit -m "added some small changes/fixxes"

malus:rebase-test neppord$ hg branch issue1

markerade arbetskatalogen som grenen issue1

malus:rebase-test neppord$ echo "fixed issue1" >> FILE

malus:rebase-test neppord$ hg commit -m "fixed issue1"

malus:rebase-test neppord$ hg up developer

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ hg branch issue2

markerade arbetskatalogen som grenen issue2

malus:rebase-test neppord$ echo "fixed issue2" >> FILE

malus:rebase-test neppord$ hg commit -m "fixed issue2"

malus:rebase-test neppord$ hg up default

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ echo "incomming changes" >> FILE

malus:rebase-test neppord$ hg commit -m "incomming chnages"

malus:rebase-test neppord$ hg up developer

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ hg rebase --keep -s default

merging FILE

warning: conflicts during merge.

merging FILE failed!

avbryter: olösta konflikter (se hg resolve, sedan hg rebase --continue)

malus:rebase-test neppord$ hg resolve -t "vim -d" FILE

merging FILE

3 files to edit

malus:rebase-test neppord$ hg rebase --continue

malus:rebase-test neppord$ cat FILE

Initial data

incomming changes

some developed code

malus:rebase-test neppord$ hg up issue1

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ hg rebase --keep -s developer

merging FILE

malus:rebase-test neppord$ hg up developer

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ hg merge issue1

merging FILE

0 filer uppdaterade, 1 filer sammanfogade, 0 filer raderade, 0 filer olösta

(branch merge, don't forget to commit)

malus:rebase-test neppord$ hg commit -m "merged issue1's fix"

malus:rebase-test neppord$ hg up issue2

1 filer uppdaterade, 0 filer sammanfogade, 0 filer raderade, 0 filer olösta

malus:rebase-test neppord$ hg rebase --keep -s developer

avbryter: cannot use revision 7 as base, result would have 3 parents

--
//Samuel Ytterbrink

Olof Bjarnason

unread,

Nov 5, 2011, 9:33:35 AM11/5/11

to pytd...@googlegroups.com

OK I'm playing around a little with the rebase extension; so far I've
gotten "hg pull --rebase" working on ordinary clone repos.

I found "glog" (enabled by graphlog= under [extensions] in hgrc file)
to be useful to understand what was happening.

Resulting history of main repo:

c:\prj\hg\rebasetst\mainrepo>hg glog
@ changeset: 2:74a8f755828a
| tag: tip
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:20:21 2011 +0100
| summary: new feature added
|
o changeset: 1:79bc50abae62
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:22:42 2011 +0100
| summary: bugfix
|
o changeset: 0:70dd5255611d
user: Olof Bjarnason <olof.bj...@gmail.com>
date: Sat Nov 05 14:16:21 2011 +0100
summary: first commit

The "bugfix" commit was done on the main repo, while the "new feature
added" commit was on a fork repo. The fork's history looks the same:

c:\prj\hg\rebasetst\fork>hg glog
@ changeset: 2:74a8f755828a
| tag: tip
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:20:21 2011 +0100
| summary: new feature added
|
o changeset: 1:79bc50abae62
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:22:42 2011 +0100
| summary: bugfix
|
o changeset: 0:70dd5255611d
user: Olof Bjarnason <olof.bj...@gmail.com>
date: Sat Nov 05 14:16:21 2011 +0100
summary: first commit

Now I want to add branches to the mix.

2011/11/5 Samuel Ytterbrink <nep...@gmail.com>:

Olof Bjarnason

unread,

Nov 5, 2011, 6:56:47 PM11/5/11

to pytd...@googlegroups.com

I finally got an hour to continue my rebase-in-hg-digging, and got it
working after some headaches and a couple of web page readings :)

Scenario: I'm working on a big feature in a branch called "some_issue"
on a repo i call "fork-temp3" locally. I want to get the latest bug
fix from "mainrepo", and I want to rebase my feature branch on it.

Here's the glog before doing the rebase:

| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:20:21 2011 +0100
| summary: new feature added
|
o changeset: 1:79bc50abae62
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:22:42 2011 +0100
| summary: bugfix
|
o changeset: 0:70dd5255611d
user: Olof Bjarnason <olof.bj...@gmail.com>
date: Sat Nov 05 14:16:21 2011 +0100
summary: first commit

As you can see, bugfix 2 has been pulled (ordinary hg pull from main
repo) into my fork-temp3 repo. Also notice the some_issue branch, the
one to the right above.

Now I want to move changeset 3 and 4 (my feature branch) "on top of"
5, the bug fix, so that it is applied "before" my feature branch in
time (and changeset history).

I have to specify what changeset I want "rebased" -- that's the first
changeset of my feature branch, namely 3. This is called the "source"
of the rebase. Figuratively, where to make the "cut" in the graphical
log tree.

Then I have to specify what changeset to placed this "cut off branch".
That is the bugfix2 changeset, named 5 in the glog.

So the full command to do the rebase when working with branches in hg is:

hg rebase -s 3 -d 5 --keepbranches

(the last flag if to keep the named branches, which we want to do
since we're not finished with our some_issue feature branch just yet).

Graphlog after this command:

c:\prj\hg\rebasetst\fork-temp3>hg glog
@ changeset: 4:fa2fbf021264
| branch: some_issue

| tag: tip
| user: Olof Bjarnason <olof.bj...@gmail.com>

| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:20:21 2011 +0100
| summary: new feature added
|
o changeset: 1:79bc50abae62
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sat Nov 05 14:22:42 2011 +0100
| summary: bugfix
|
o changeset: 0:70dd5255611d
user: Olof Bjarnason <olof.bj...@gmail.com>
date: Sat Nov 05 14:16:21 2011 +0100
summary: first commit

Notice that it's one changeset less than previously; the changeset
that disappered was the "I have built a new branch and have to
commit"-changeset.

This is the first time I've done a rebase operation, but it sure isn't
the easiest thing to grasp in the DVCS world. I guess git does this
more "naturally" than hg?

2011/11/5 Olof Bjarnason <olof.bj...@gmail.com>:

Samuel Ytterbrink

unread,

Nov 5, 2011, 7:31:30 PM11/5/11

to pytd...@googlegroups.com

What happend with deafult?

and what i did wich dident work was when i needed to rebase to 2 different issues then merge 1 and rebase teh other..

2011/11/5 Olof Bjarnason <olof.bj...@gmail.com>

--
//Samuel Ytterbrink

Olof Bjarnason

unread,

Nov 6, 2011, 2:08:49 AM11/6/11

to pytd...@googlegroups.com

2011/11/6 Samuel Ytterbrink <nep...@gmail.com>:
> What happend with deafult?

It doesn't show in the glog, since some_issue is based on it and there
is no newer changeset than those of some_issue.

So after adding a file in main repo, and pulling it into fork-temp3, I
got it visibly back again:

|/ branch: some_issue
| user: Olof Bjarnason <olof.bj...@gmail.com>

hg rebase -s 4 -d 5 --keepbranches got me:

c:\prj\tmp\rebasetst\fork-temp3>hg glog
@ changeset: 5:27279a77a025

o changeset: 4:b4b6a7d3221e
| user: Olof Bjarnason <olof.bj...@gmail.com>
| date: Sun Nov 06 07:32:40 2011 +0100
| summary: New file

> and what i did wich dident work was when i needed to rebase to 2 different

> issues then merge 1 and rebase teh other..

I guess you would do one after the other?

A comment about the rebase: If the branch has a lot of commits, it
might be inconvenient to find the number of the first commit (with
glog for example). But rebase has a convenience version of "source"
called "base" (-b). With -b it is enough to specify any one of the
commits' numbers on the branch (for example, the latest), and then
rebase will look up the first commit on that branch automatically, and
make the cut there.

Remember to add the --keepbranches flag (not the first time hg forces
us to add flags which seem to be the default, I remember something
similar going on when closing a branch).

Reply all

Reply to author

Forward