Mercurial vs Git

Eoin Coffey ecoffey at
Wed Jan 19 22:13:16 EST 2011

I took the liberty of illustrating this on github.  Mostly for my
benefit, since your conclusion seemed wrong, but I couldn't be sure
until I walked through it :-P

In short: Yes they will see your history, but not necessarily your branch.

I followed your example and it lives at :

You'll notice
only lists master, but shows all the
'B*' commits happening in a second line of commits and then the merge.

So yeah the branch rlaager-foo is just a pointer to a commit;  And to
push the "branch" (which is the set of 'B*' commits) you do not need
to push the handy label that points to the head of that branch.  Which
almost kind of makes sense!

And here is what I did at the command line to reproduce this in git:

mkdir pidgin-illustration; cd pidgin-illustration
git init
touch A1.txt
git add A1.txt ; git commit -m 'A1'
git push origin master

git checkout -b rlaager-foo # this creates the branch and switches to it

touch B1.txt; git add B1.txt ; git commit -m 'B1'

# Repeat above for B2, B3

git checkout master

# Repeat touch, add, commit for A2, A3

And then finally:

ecoffey at aenea : ~/Code/pidgin-illustration
$ git branch
* master

ecoffey at aenea : ~/Code/pidgin-illustration
$ git merge rlaager-foo --no-ff
Merge made by recursive.
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 B1.txt
 create mode 100644 B2.txt
 create mode 100644 B3.txt

ecoffey at aenea : ~/Code/pidgin-illustration
$ git log -n 1
commit 6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1
Merge: e9e3659 ecf1201
Author: Eoin Coffey <ecoffey at>
Date:   Wed Jan 19 20:00:27 2011 -0700

    Merge branch 'rlaager-foo'

ecoffey at aenea : ~/Code/pidgin-illustration
$ git push origin
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (12/12), 1.01 KiB, done.
Total 12 (delta 6), reused 0 (delta 0)
To git at
   c4c7b1d..6fc76c5  master -> master

I used the --no-ff option to specify that git should do a 'fast
forward' merge.  This makes sure a individual merge commit is
generated to match the example you were describing.

Anyways, hope that helps.


On Wed, Jan 19, 2011 at 7:24 PM, Richard Laager <rlaager at> wrote:
> On Thu, 2011-01-20 at 01:17 +0200, Felipe Contreras wrote:
>> And of course, branches are disposable (supposing I'm 'darkrain'):
>>  git checkout master
>>  git merge docs # the commit would say 'Merge branch 'docs' into master
>>  git push origin master # push the 'master' branch to the 'origin' repo
>>  git branch -d docs # delete this branch which won't be used any more
> Let's suppose that the tip of Pidgin's main line of development
> (trunk/master/etc.) is revision A1.
> I make a branch, called "rlaager/foo" (or or rlaager-foo),
> of A1. I commit a change, revision B1. Then I commit another change, B2.
> Meanwhile, someone on trunk commits A2 and A3. So we have this:
> A1
> |  \
> A2  B2
> |    |
> A3  B3
> Conceptually, we developers think of A1..A3 as the trunk, and A1..B3 as
> the "rlaager/foo" branch. So far, none of these concepts should vary
> with any [D]VCS that supports branching.
> Now, imagine I merge B3 back into "trunk" to get A4:
> A1
> |  \
> A2  B2
> |    |
> A3  B3
> |  /
> | /
> |/
> A4
> This merge is possible in git, hg, and other [D]VCSes not relevant here.
> Now, assuming I push this to our central repository in the "usual way"
> for git/hg, if John looks at the history, is there a way for him to
> identify that B2 and B3 were part of the "rlaager/foo" branch?
> As I understand it, with Mercurial, B2 and B3 would be (immutably, I
> think) marked as having been a part of the "rlaager/foo" branch, so the
> answer would be yes.
> As I understand it, in git, branches are basically mutable tags, so the
> answer would be no. Is this correct?
> Richard
> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list