If you have both branches and a way to close them, then you have a much simpler way to get a feel for the history of the code. You know at a quick glance what sort of major work has gone on and what's still ongoing.

If you don't have that you'll end up inventing more complex ad-hoc schemes to get it (merging a branch, deleting it and tagging the merge commit is an example of one such scheme, and it doesn't do the same thing).

And the ability to mark branches as closed in Mercurial is, to me, an indication that the developers put some thought into the different use cases for branching and wanted to cover more of them than git's standard workflow does ;)

In lots of ways git is a superset, branch workflow included.

A superset which doesn't include everything that's in the alleged subset? That must be a new definition of "superset" that I haven't heard of yet...

From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?

http://pragprog.com/titles/tsgit/pragmatic-version-control-u...

The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it.

Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.