[geeklog-devel] Merge vs. Rebase

[Dirk Haun]

When you take a look at our Mercurial repository right now, you'll
notice a rather odd timeline for the latest couple of changes:

--- snip ---
2 weeks ago	Dirk Haun	For Remote Users, display their service name in
the User Editor
2 weeks ago	Dirk Haun	Replaced hard-coded 'N/A' with $LANG_ADMIN['na']
2 weeks ago	Dirk Haun	Use COM_numberFormat to format the number of
registered and anonymous users displayed in the Who's Online block
5 days ago	Dirk Haun	Added tag geeklog_1_6_0_stable for changeset f461a0655b76
--- snip ---

So how can changes from two weeks ago end up being on top of newer changes?

Two weeks ago, I made those changes on a separate branch. 1.6.0 was
almost done, so I didn't want to introduce new changes at the last
minute, but I had some free time and wanted to prepare a few things for
future Geeklog versions.

So far, so good. So now that 1.6.0 is out, how can I get these changes
into the main repository? The standard way would be to do a merge
between 1.6.0 and my feature-branch (the name of my local repository).

A merge would
1) introduce an additional merge commit
2) hide the changes somewhere in the history, since these changes
happened two weeks ago

For this and other situations, an alternative approach is to do a
rebase. Here's a nice article that explains things better (and with
pictures) than I could:

<http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-
into-the-mysteries-of-revision-control/>

In a nutshell, a rebase cuts out the changes from the feature branch and
applies them on top of the current branch. And this is exactly what I
did here.

I know that a few people (including our GSoC students) are working on
new features using their own branches and I just wanted to point out an
alternative to merging. Whether using merge or rebase makes more sense
depends on the context and the type of changes, I guess.

bye, Dirk


-- 
http://www.geeklog.net/
http://geeklog.info/