I’d heard of patches, but I haven’t found a real good source of information on how it compares to local branches + rebasing. For example, with Git, I always work in a local branch. I don’t decide on what queue to put it in, I’m just working on a certain topic. Looks like I need to investigate more.

let’s say now that you have been basing your queue on changeset x, and by commit time you realize that changeset y should be the parent. so you just hg up y, and apply the queue. if there are conflicts, you can go back to x, apply, and with the queue in place go back to y. mercurial will do the merging onto the patches for you! and you can just apply. very flexible.

hope this makes sense.

The git workflow is appealing though, however it requires me to know about the behavior (when are they moved etc.) of all those revision bookmarks.

However, writing a mercurial extension that keeps track of you bookmarks shouldn’t be all too difficult. Did I ever mention I wanted to learn python anyway

In the anonymous branch case, suppose I do 5 commits, then a bug comes in.

In Git, I would now switch back to “master”, do a pull –rebase, then start THAT work on another local branch. How would I switch back to “master” in the anonymous branching case?

I couldn’t find a way, which is why I went for the bookmark of “master” that tracks the local “trunk” (mirroring the remote default branch). I don’t want to go just based on ref #’s to “figure out” where I should rewind time to.

I dont see any scenario git supports that hg doesnt (in terms of branching).

>.but one thing about Git branches is that I don’t have to decide up front the nature of work I’m doing.

Thats actually a case for anonymous branches as hg has them. You can name a branch anytime via bookmark.

Named branches aren’t for short but rather for long lived branches (such as trunk and stable).

I’m still very new to Hg, so I think my next attempt will be to do named branches. Named branches + rebase might also do the trick as well.

Nice writeup. I always enjoy seeing other workflows like this. Any particular reason you’re staying away from named branches? Is it due to the fact they live in your revision history?

I think this is one of those “to each their own” things. Git branching is about as simple as can be, as a Git branch is simply a named pointer to a commit. Hg branches are much more intrusive, as that metadata lives with each commit. I’ve never personally had to remember where things go, I just look at my repository browser to visualize it. Anyway, Git is super smart about that kind of thing.

I’m not necessarily trying to replicate my Git workflow, but rather, the workflow I use which Git supports. I’ll take a look at anonymous branching….but one thing about Git branches is that I don’t have to decide up front the nature of work I’m doing.

It’s not just to stay in the same directory. It’s to stay in the same repository. For me, it’s important to visualize the history to understand what came where, so I keep the repo browser open 100% of the time. When I have three branches open, but in separate folders, I don’t really have one view of where they all came from.

Single directory = single repository. It’s really not hard to switch items in a local repo, that’s what hg update is for. Git does it very easily, I don’t see why Hg should be any different. With a single repo, I can now view ALL the work going on in my repository, instead of looking across all my separate, local forks. Coming from the Git side, this is extremely useful.