Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Does the standard branch workflow still expect you to have a separate repository and directory per branch?

You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo).

> I don't care about plugins

That's stupid, mercurial is very much about plugins: there are dozens of official plugins shipped in a standard mercurial install.

> the standard workflow

there is no such thing.

> Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"?

All of them are provided in the base install, you just have to enable the corresponding extensions.



Furthermore, he's probably confusing mercurial with something that don't even exist

bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem

(I just wished that git people actually knew how do other tools work... but, alas! Now it's too late for underdogs like bazaar or darcs to catch up)


> bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem

Shared repositories didn't originally exist and IIRC were added to avoid data duplication. Furthermore, they don't fix the multiple working copies problem (you have to use lightweight checkouts or collocated branches for that).


> bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem

Those are functionally equivalent, in that they both mean branching is not instantaneous.


Those are functionally equivalent, in that they both mean branching is not instantaneous.

They are not functionally equivalent. A "bzr branch" with a shared repository will only populate the working tree and does not have to duplicate the repository. It is functionally closer to "git-new-workdir" than "git clone" or "git branch".

To have instant branching in Bazaar, you can use co-located branches.

Branches with their own directories exist for the use case where the accumulated cost for rebuilds after branch switches is more costly than populating a new directory with a checkout or if you need two checkouts in parallel. They also exist in Bazaar for simulating a workflow with a central server and no local repository data.


Mercurial's branches are server side (learned that the hard way the first time I made a branch), git's are client side.


This is a description which makes no sense whatsoever, given git and mercurial are both DVCS there's no "client" or "server".

1. Mercurial branches are commit metadata, the branch name lives in the commit. Git branches are pointers to a commit (which move when a new commit is added on top of the existing branch commit), living outside the commit objects.

2. As a separate concern, Git has multiple branch namespaces ("remote" versus "local" branches, where each remote generates a branch namespace, and remote-tracking local branches). Mercurial only has a single namespace.


I think you are confused, git and hg branches are very similar (I'd try to help but I'm not sure what the confusion is).


It's simple: I created a local branch, worked on it, then tried the git workflow:

1. Switch to the default branch

2. Cherry-pick (with the equivalent hg command) my changes from my own branch into default

3. Push the changes to the remote repo

What happened was that my local branch got pushed to the server, along with the default one. With git this wouldn't happen, it would push the local master to the remote master.


Yes, by default all branches are pushed, (you would have to use --force if it creates new heads, and --new-branch to push new named branches). But I really don't see how it makes anything "server" or "client" side.

(and you could in any case decide to push just default: hg push -r default)


This is because hg pushes all changesets by default. There are two workflows in hg that would get you what you want:

hg push -b default

Pushes only changesets from the default branch. You can also do these with phases by marking your branch as private.


Much of http://www.stationary-traveller.eu/pages/bzr-a-retrospective... applies equally well to Mercurial.


What parts? That's a very long post. I don't think the overall melancholy tone of defeat applies at all. Hg is a lively and healthy project, and the most frequently offered alternative to git with plenty of commercial backing (Facebook, Google, Atlassian, Microsoft...)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: