Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Does the standard branch workflow still expect you to have a separate repository and directory per branch? I don't care about plugins, here; if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does.

Likewise, does the standard workflow still intentionally make it painful to rearrange changes in your local repository to construct a series of patches? Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"?

View on HN

> if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does.

There is no real standard workflow. There are tools in place to build whatever you want. This is old, but remarkably still relevant:

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

If you want git-like branches, Mercurial bookmarks are close, but not quite the same. They have some intentional differences, which make sense and do not impede you, but will not make sense if you absolutely want them to behave like git branches.

> "commit --amend", "rebase -i", and "add -p"?

hg commit --amend, hg histedit, hg record (but hg crecord is much nicer).

They're built-in, but you have to flip them on the last two with a config switch.

That post helped, and bookmarks might get the job done, but the mercurial culture doesn't seem to encourage them compared to branches. As a result, you tend to find a lot more separate mercurial repositories than single repos with bookmarks, and a lot more named branches with hard-to-eliminate commits as well (since even "closing" a branch doesn't really get rid of it).

> hg commit --amend, hg histedit, hg record (but hg crecord is much nicer).

> They're built-in, but you have to flip them on the last two with a config switch.

And that's the fundamental attitude that I can't stand in mercurial's culture: "careful, you might accidentally throw away that information you specifically wanted to throw away". Those commands aren't available by default because the culture doesn't encourage that workflow, so even if you use them for your own personal workflow you'll tend to find a lot more junk commits and forever-remembered branch names in the average mercurial repository.

I might have read this wrong, but safety for newbies doesn't sound all that bad to me.

History editing in git is not unsafe: because it's a part of the default set of tools, git offers functionality like the reflog to keep track of old history locally and avoid losing it. It's extremely difficult to permanently lose content in a git repository even using the history editing commands; it's always just a "git reflog" away.

History editing in Git is actually perfectly safe. The old commits will (at least initially) still be there, though you may need "git fsck --unreachable" to locate them if you don't remember the hashes or have them in your reflog anymore.

What is unsafe in Git is garbage collection. Commits that aren't reachable from either a branch or the reflog will be deleted after a grace period (assuming that you don't disable garbage collection entirely). More importantly, unreachable commits will also not be pushed with "git push" (which means that if your laptop blows up, you may not be able to recover them from a repository server).

This happens not directly as a consequence of history editing, but generally because a branch is being pointed to a new commit or removed (which also implicitly happens during history editing).

It's not technically unsafe, but it's unsafe from a UI point of view. It obviously confuses some inexperienced people (witness the confusion in this thread), making them feel helpless and like their work has been destroyed, even if it hasn't. Both git and hg actually have lots of fallbacks so that work is never lost, but without experience, these fallbacks may not be obvious.

Hg's rewriting extensions are sometimes disabled by default for this reason: until people understand how they work, they shouldn't use them. If they try to use them, hg tells them how to enable these features.

> Those commands aren't available by default because the culture doesn't encourage that workflow

That's not the reason. The reason is that they want to keep the standard interface to hg minimal. Unfortunately, I cannot find a citation for that right now.

That said, I, too, would appreciate having more standard extensions enabled by default. But direct your disagreement to the idea that hg should have a minimal standard interface instead of making up reasons :)

Note that extensions that ship with Mercurial are exactly as supported as the tool itself, and come with the same kinds of backwards compatibility guarantees. It's not worth worrying about rebase, histedit, and record being extensions - if you want them, turn them on and use them.

They're not exactly as supported, because they're not on by default, and they're not the thing everyone in the Mercurial culture tells you to use as the obvious solution to problems. Version control is as much about what other people do as what you do, and what other people do tends to align most closely with the defaults and what the tools encourage.

No, they're exactly as supported. What I meant by that was that we promise to not break them, ever, to keep the output formats stable, and accept bug reports for them. That doesn't necessarily mean it's something we'll always recommend (eg mq isn't something I'd recommend for a new user, rebase/histedit/amend are way better and always will be.)

We don't turn them on by default for two reasons: newbie users not shooting their foot off unexpectedly, and UI clutter. mq alone (which we actually recommend avoiding now if you don't really need it) adds a bunch of verbs to the command line interface.

We've talked about having an 'hg hello' command or something that'd give you a proposed template hgrc that suggest you might want rebase/record/histedit/pager/color/progress, but nobody's worked out exactly what that should be like. Does something like that sound like it might be helpful?

Could you elaborate on why to avoid mq?

It's a very powerful tool, but also a complex one, and one which brings in a bunch of new commands. There are a bunch of extension which provide nice UIs to various subsets of mq's full power, and are much simpler.

If you need mq, use mq, but if you just need to e.g. do some history edition, use histedit.

Some people like it, but my basic complaint with it is that it introduces a new concept, the "patch", that is basically a crippled commit. When a patch is not a commit, you get rejected diff hunks when it fails to apply, and it can easily forget its history.

An MQ patch is basically a commit that doesn't know how to merge and doesn't keep backups. It's way too easy to make a mistake and lose work. I consider MQ one of hg's youthful mistakes before tools like histedit, rebase, and Evolve came to exist.

mq keeps its patches as an internal per-repo stack. This is much weaker than git's tree branches.

Here's an example: let's say I've been working on a repo, and have 2 current mq patches called A and B pushed. There's no way for me to pop A and B, then apply another patch called D in the current repo (at least as far as I could figure out). Also, even if there were, I'd have no way of then pushing A and B on top of D. The patches only work as a linear stack (D must come on top of B).

I do this all the time. Pop B, pop A, reorder patch queue to put D first, push D, push A, push B. Check the docs.

In response to your last sentence, yes.

+1 for the 'hg hello' idea.

I have wondered why they're called "extensions" rather than "modules", which I think would characterize their actual use better.

There are only two hard problems in computer science: cache invalidation and naming things. - Phil Karlton

> They're not exactly as supported, because they're not on by default

I really don't get this. In almost any software there are features that are not 'on by default', but it's still implemented and supported (except explicitly stated otherwise). How can this be a reason to not use the functionality when you need it?

It's like using Outlook to respond to mail on a mailing list. Sure, it's theoretically possible to use some combination of manual configuration and extra work to construct a post that won't violate social norms, but the tool doesn't encourage it, so mailing lists with a significant number of Outlook users on them tend to fail to follow the standard mailing list conventions of other lists, and develop their own conventions.

The same holds for any tool used in a workflow that involves anyone other than yourself: any tool with a default workflow tends to encourage people to follow that default workflow.

The fact they are not on by default seems to actually be hurting Mercurial in the debate against Git. As every review of "Mercurial vs Git" assumes they are not available, just because they are not enabled in default configuration out of the box.

Maybe Mercurial should start shipping them enabled?

I would rather they be made easier to enable (currently one has to edit an .INI file). That would be better than trying to appease some hypothetical from-Git converts.

> 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

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.

> 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).

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...)

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

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.

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.

Mercurial refers to git-like lightweight branches as bookmarks [1]. Branches are still permanent tags in the repository.

Commit --amend is now part of base mercurial. Rebase is available as an extension that is shipped with the client, like most advanced functionality. I don't know what add -p does.

[1] http://mercurial.selenic.com/wiki/Bookmarks/

"add -p" is basically the 'hg record' extension.

It's more like `git commit -p`. If you abort `hg record`, the selection you've made is lost.

Let me translate: "if this tool is not exactly like Git, I will not use it".

That sentiment comprises a truly mindblowing number of "bug" reports that hit the Mercurial mailing list every month. I honestly wonder sometimes if I'm simply forgetting how CVS users did the same thing when Subversion shipped and I forgot about it/missed it, or what.

svn was designed to be "CVS done right," which informed a lot of the design and workflow to the point that some CVS misfeatures only got carried through by virtue of that mandate.

(Source of this assertion is prolonged discussions with sussman, one of the early svn authors.)

Not exactly, but close. Switching away from Git would require a tool that is both compellingly better in some key way as well as not worse for any existing workflow. I have yet to see any other version control system that meets both of those criteria, even leaving aside the network effects of using the most popular system.

I work in several branches in the same file system directory. Branching in mercurial is as simple as "hg branch branchname", and switching branches is just "hg update branchname". As long as you make sure you commit everything you can easily work in one directory.

Merging changes across branches is easy too, as you only need to specify the revision number.

If you push while having open local branches, they get pushed to the remote (or at least that's how it was last time I used them). That's not what you want, in most cases (git branches are local).

Mercurial won't push new branches unless you specify -f or --new-branch. You can selectively push only the branches you want with hg push -r branch_or_revision (hg push -r . for the current revision). You can also hide branches using phases, so they won't be pushed even with -f or --new-branch.

The guide from [1] confirms it works the way I saw it (it pushes all branches):

Mercurial will push/pull all branches by default, while git will push/pull only the current branch.

Did this behavior change in recent versions of hg?

1 - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

Mercurial will attempt to push all branches. It will then immediately stop with an error message unless you specify -f or --new-branch if you're trying to push a branch that does not already exist in the remote repository (or even to create a new head in an existing branch). In order to get rid of the error message you need to either (1) explicitly tell Mercurial to push all branches, (2) specify which existing branch(es)/revision(s) you want to push (they must already exist remotely), or (3) hide the branch with hg phase secret -f. This means that your local branches will not leak into the remote repository unless you specifically instruct Mercurial to do so.

Of these, only the phase approach is new (2.1+). The rest hasn't changed.

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit.

It's conceptually lightweight.

Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.

Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.

Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?

According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.

Well, if that true, I'd prefer to investigate and make them fast, instead of using "bookmark-as-a-branch" because of all the cool stuff mercurial branches have (like great log-drawing with branch info).

Not true any longer.

As described in http://mercurial.808500.n3.nabble.com/named-branches-vs-book...

> We have users with thousands of named branches in production and have > done tests on up to 10k branches and the performance impact is fairly > minimal.

Reply on news.ycombinator.com