Posts Tagged ‘Version Control’

Review remote changes offline in Mercurial

If you want to review remote changes from Mercurial offline you cannot use hg incoming. For sure there is a nice way to do it. So here is what I do to get changes from a repository to review them later without pulling them into my repo before reviewing. It also has the advantage that you can review changesets that include a given file. This is not possible with hg incoming.

Read the incoming changes and save them in a bundle file:

$ hg incoming --bundle incoming.bundle

Now you can disconnect and review them offline.

$ hg -R incoming.bundle log --no-merges -p -- hgext/
(log pops up)

The -R incoming.bundle option tells Mercurial to use the bundle as an overlay for the current repository. The –no-merges option tells Mercurial to not display merges (which I usually use for reviewing patches) and the -p option is there to display the applied patches in the output. I use — hgext/ to display only changesets related to the bookmark extension.

Everything’s good, let’s pull it:

$ hg pull incoming.bundle
pulling from incoming.bundle
searching for changes
adding changesets
adding manifests
adding file changes
added 113 changesets with 281 changes to 204 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

Writing a hg to subversion gate

Using a decentralized version control system (DVCS) like Mercurial (hg) or Git as a client for Subversion is very common. With the unique features of a DVCS a developer can have both the features of offline development and local branching while still being able to push to a subversion server. This approach is often used in environments in which subversion is the given version control system. While the approach of using this bi-directional push and pull mechanism, provided by git-svn or hgsubversion, works perfectly for one developer, it has limitations working in a team using the usual DVCS push and pull concepts.

The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.


git2svn, a little bit of git voodoo.

Interacting between git and subversion is quite common. The git command git-svn can be used to import existing subversion repositories into git and commit synchronize commits between two repositories. While importing a subversion repository into git is common, importing an git repository into subversion is quite unusual. There are various tools to do so, but most of them require direct access to the svn repository. In fact it is possible to use git-svn to get that job done. Frankly it requires some git voodoo and knowledge of the graft-feature. We’ll do a sample import using grafts, but before we start, we’ll explain the theory behind the import.

Merge vs. Rebase – A deep dive into the mysteries of revision control

I remember the days when I started learning Git about two years ago. I crawled through all the available commands and read the man pages what they are for and I remember when I stumbled over rebase and stuck. After figuring out what it actually does, I start loving it, but didn’t understand it’s dangerousness until someday I somehow got duplicated commits after pulling from another repository. So let me explain what goes wrong and why merge and rebase are often misunderstood. I’ll also present a list of golden-rules about their usage. Before we start with explaining both commands, I would like to give you one of the most important rules, in case you don’t want to read the complete article.

Never rebase branches or trees that you pulled. Only rebase local branches.


GIT vs. SVN: 2:0

Again, git vs. SVN. Last time, it was big win for git. And guess what, git will strike again.

I mean nobody is perfect (expect Linus, but there is just one – as he mentioned once), so we actually fail writing bugfree code. Therefore we end up sitting in front of a huge code base trying to figure out what’s wrong. Thanks to our agile development process we usually end up fixing code we are not into.

So the facts:

  • We don’t know the code
  • We don’t have a clue where to search
  • We are lazy

Okay, if we drop 1. and 2. we still have to find out what went wrong. So as we tend to get our evening beer fast and don’t want to waste time, we use git bisect to find out when the problem was introduced.

Assume following commit history:

a –> a’ (bug introduced) –> b –> a” –> c

When we bisect the problem, we will end up doing a quick search on the commits, marking buggy commits/trees bad and those that work fine good. This means, we mark c as good, then git will take us to a. We mark that commit as good, which will git move to b. If we mark b bad, git knows that a’ must introduce the bug. Than just view the diff and you might know where to find the bad code and how to fix it.

Well, as long nobody trashed the history with their ‘fixed a hundred bugs’ commits, containing like thousends of unrelated changes. In those cases, just bisect your collegue. git vs. SVN: 2:0

take it with humour

GIT vs. SVN: 1 : 0

I used git for the last 6 month in a big project. The project itself is not maintained
in git but in subversion as this is what developers know and what project leaders like to use
for several reasons.

In fact it’s not a bad idea to actually use subversion as version control system, particularly if
the developer are used to it. Well, I don’t care about that. Thanks to git-svn I could use
git as my subversion frontend. For sure, the distributed architecture of git didn’t help me that much when it comes to exchanging changes as I was the only developer using git.

But thanks to the repository format and git rich featureset, I found myself using git in a
much more productive way than people could use subversion.

What I really love is pickaxe. You can use that feature by passing -S to git log causing the log
to search for the string in the commit history and display all the commits that contain these changes.
Actually one of our developers had a problem with a blur event in the java script code, causing
all forms in the script to lose their focus all the time. He was just searching for the point all the
time as going through the commit messages was obviously too much time consuming (with about 100 commits per day). To make a long story short: I’m really a Javascript dumbass, but I just picked the
latest commits having a blur in their name with git log -Sblur and I found 2 promising commits. Showing him the commits actually solved the problem. He just missed one point in the thousands lines
of Javascript containing the blur event that caused the problems. Okay so here are the statistics for that event: Subversion with incremental search, but Javascript knowledge: 3hours. Git without any knowledige and a lazy person using it: 10mins. GIT vs. SVN: 1:0

Experimental PHP 5.3 Tree

Approaching the 5.3 release of PHP, a lot of features were introduced
and discussed at the internals mailinglist. This includes closures, traits
and various other patches. Some of these patches are on hold and not yet
applied. Therefore only a few people can take a look at the new features. Particularly because they scare patching PHP themselves or they run into troubles while patching. To make those patches available for a wider audience
I start maintaining a PHP 5.3-exp branch containing experimental features and

Who is the audience:

  • (Core) Developers that don’t want to maintain their own patch series
  • Developers that want to discuss recent proposals at the mailinglist
  • PHP lovers, that want to keep up-to-date

The 5.3-exp branch is available at:

Latest tarballs are available at:

Please notice that experimental patches are untested and therefor can cause
problems. Also notice that I cannot guarantee that the patches run under every
platform supported by PHP. The patchset is tested under a recent Ubuntu Linux
system with latest re2c and librarys from the Ubuntu repositories.

Comments are welcome

6 month and a small set of bash scripts

Well finally gc-utils turns 6 month old. It started as a small script to wrap my usual command line of git-cvsimport. After getting nerved by specifying the GIT_DIR all the time the script started to grow to do help me importing repositories. Since that a lot changed and gc-utils is now on version 0.2.2. And the best: thanks to Adam Mercer we finally have a macport.

I love you, INDEX

Okay, there wasn’t a blog entry on git for quite a while, but well, here it is. This time about the incredible INDEX mechanism and git add -i. (more…)

gc-utils v0.2.0 released

A lot has changed since the latest announcement on the blog. We brought up the major release v0.1.0 that brings gc-utils into production status. Since 0.1.0 gc-utils now uses an own remote branch to pull things into before rebasing the CVS changes on top of the master branch. Additionally we cleaned up some smaller notifications. v0.2.0 was pretty much done by Jan Günter, who restructured the sources and cleanup the makefile so that we get a much nicer generation of files. Additionally Ping Yin, who is currently working heavily on git and tools around git fixed a issue with cvsps that might occur in particular environments. Finally we prepared gc-utils to be able to detect a brighter range of git versions to verify if gc-utils can be used with those git versions.

Let’s do it the git way and just provide the diffstats between v0.4.0 and v0.2.0:

David Soria Parra (32):
Add a “Update…” message to
Check if the a .cvs directory is present.
Fix the check for the .cvs directory.
Aggregate duplicated code into on library file.
Add license header
Test to invoke gc-utils from subdirectories
Testcase for gc-commit
Import branches into refs/remotes/cvs/* by default
When running cvsclean, gc-commit didn’t return to the working directory
Check if the directory to import already exists.
Change required git version from 1.5.0 to 1.5.4
Tests: Test merge strategy option in gc-update
Tests: Display filename when a test fails
Tests: Silence cleanup script
gc-utils version 0.0.5beta1
Add UPDATE-NOTES containing informations about compatiblity breaks
Silence git-stash when gc-update is not in verbose mode
Pop stashed status always, not only when we rebase
Fix the check for the .git and .cvs directory
Cleanup manpages
Use die shortcut instead of echo >&2 && exit 127
Show a message that we run cvs update
Silence errors due to non integer inputs in our select
Simplify code
gc-utils version 0.1.0
Let install(1) create our directories
Change required git version from 1.5.4 to 1.5.3
Fix the check for git versions
Tests: Wait a second before recommiting a change
Merge branch ‘maint’
Merge branch ‘master’ into next
gc-utils version 0.2.0 the ‘yellow t-shirt’ release

Eduardo Cardoso (2):
Uses –no-pager to retrieve log messages.
Added flags to `cvs update’ to allow creation of directories and pruning of empty directories.

Jan Günter (7):
Added .gitignore file
manpage syntx correction
Removed the manpage numbers from gc-utils commands output
Update mandb after installing manpages
Suppress sed commands in Makefile output
Restructuring project files
Code cleanup

Ping Yin (1):
Sometimes “cvsps –cvs-direct” may not work, so use -gn to allow

.gitignore | 8 ++
ChangeLog | 107 ++++++++++++++++++++++
Makefile | 69 +++++———-
doc/.gitignore | 9 ++
doc/Makefile | 46 ++++++++++
doc/gc-commit.1 | 46 ++++++++++
doc/gc-import.1 | 63 +++++++++++++
doc/gc-multi-commit.1 | 29 ++++++
doc/gc-update.1 | 54 +++++++++++
gc-utils.1 => doc/gc-utils.1 | 26 +++—
gc-commit.1 | 45 ———
gc-import.1 | 56 ————
gc-multi-commit.1 | 29 —— | 182 ————————————–
gc-update.1 | 54 ———– | 158 ———————————
src/.gitignore | 9 ++
src/Makefile | 63 +++++++++++++ => src/ | 68 ++++———– => src/ | 84 +++++++———–
src/ | 147 ++++++++++++++++++++++++++++++
src/ | 44 +++++++++
src/ | 138 +++++++++++++++++++++++++++++ => src/ | 54 +++——–
tests/ | 29 ++++++
tests/ | 21 +++++
tests/ | 29 ++++++
tests/ | 4 +-
tests/ | 17 +++-
tests/ | 2 +-
tests/ | 4 +-
32 files changed, 968 insertions(+), 736 deletions(-)
create mode 100644 .gitignore
create mode 100644 UPDATE-NOTES
create mode 100644 doc/.gitignore
create mode 100644 doc/Makefile
create mode 100644 doc/gc-commit.1
create mode 100644 doc/gc-import.1
create mode 100644 doc/gc-multi-commit.1
create mode 100644 doc/gc-update.1
rename gc-utils.1 => doc/gc-utils.1 (66%)
delete mode 100644 gc-commit.1
delete mode 100644 gc-import.1
delete mode 100644 gc-multi-commit.1
delete mode 100755
delete mode 100644 gc-update.1
delete mode 100644
create mode 100644 src/.gitignore
create mode 100644 src/Makefile
rename => src/ (57%)
rename => src/ (54%)
create mode 100644 src/
create mode 100644 src/
create mode 100644 src/
rename => src/ (53%)
create mode 100644 tests/
create mode 100644 tests/
create mode 100644 tests/

gc-utils is a small set of bash scripts that wrap git-cvsimport(1) to make importing cvs repositories and exporting commits back into cvs easier. It is licensed under the terms of the MIT/2-Clause BSD license. gc-utils is available at