On Wed, Oct 7, 2009 at 5:45 AM, Magnus Lie Hetland <[email protected]> wrote:
> On Oct 7, 2009, at 05:07, Mark Lodato wrote:
>>>> [...] I much prefer git to hg.
>
>> * git branch - no equivalent
>
> I don't know git, really ... is it possible to sum up the main
> differences between this and "hg branch" briefly?

Briefly: They do the same thing.  The difference is that *other* git
commands honor the current branch, while other hg commands (besides
"commit") ignore it.

For example, make a new branch, make a commit, and then switch back to
the original branch.  Now, what does log or view or tip or export or
... say?  In git, they show you the current (i.e. original) branch, as
if the new one did not exist.  In Hg, they show the new branch as if
the original one (the one you're currently on!) did not exist.  So,
what's the point of branching in Hg?  Am I missing something?

In general, Hg prefers "heavyweight" branches, where each branch is a
clone (i.e. not using "hg branch"), while git prefers "lightweight"
branches, where a "branch" is just a tag that is automatically updated
when you commit.*  This makes branching and merging very fast and very
easy in git.  It changes the way you work because it is so quick.

Statements like the following have discouraged me from using hg branch:
- "However, a good rule of thumb is to use branch names sparingly and
for rather longer lived concepts like "release branches" (rel-1,
rel-2, etc) and rather not for short lived work of single developers."
[1]
- "Mercurial does not yet offer a foolproof way to back out an
erroneous merge." [2]
- "In practice, this is something you won't do very often, as branch
names tend to have fairly long lifetimes." [3]

See also: http://whygitisbetterthanx.com/

-- Mark

[1] http://mercurial.selenic.com/wiki/Branch
[2] http://mercurial.selenic.com/wiki/NamedBranches
[3] 
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#x_390

* To see how lightweight branches are, you can manually "git branch foo master":
    $ cp .git/refs/heads/master .git/refs/heads/foo
What are these files?  Just a commit id:
    $ cat .git/refs/heads/foo
    faba5d52ae82239f522c108b51fa18dbb1ae9a8b
What does "git checkout foo" do?  Besides updating the working copy,
it basically does:
    $ echo "ref: refs/heads/foo" > .git/HEAD
Most of the other git commands are simple as well.  This is another
reason why I like git - I can understand it!
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to