My 2 cents, as a LWN "professional hacker": Mercurial planning to transition away from SHA-1

 

LWN article:

Mercurial planning to transition away from SHA-1
https://lwn.net/Articles/832111/

My comment:

https://lwn.net/Articles/833425/

Content of my comment:

My 2 cents, as a LWN "professional hacker":

Existing Mercurial users are using Mercurial with existing old-and-aging Mercurial repositories that use SHA-1.
At my job, we use Mercurial, because it is what it is.
Unless an existing repository can have both old SHA-1 hashes and $NEW-HASH hashes at the same time, I don't think that this is going to be a thing. Users just don't care.

Branching

You can think of Mercurial branches as Commit Namespaces rather than true branches as intended by CVS, Subversion, Git and really computer science in general. In Mercurial, each commit belongs to a Mercurial branch explicitly and forever. (The information of branch name is encoded in the data of a commit.) In Git, a commit does not contain in its data the branch name.

So, what did Mercurial do to fix that, in order to add standard branching semantics to replace "Mercurial Branches" ?
Bookmarks !

In Mercurial, bookmarks are basically Git branches. (A temporary label on a commit, that will advance as you add commits on top.) In Mercurial, most commands (push, pull, export, ...) support "bookmarks". You can do "hg push origin -B topic", which is equivalent to "git push origin topic". But, "hg log" does not have the -B switch for bookmarks.

In August 2020, I submitted patches to add bookmark support in the "hg log" command.
The patch https://phab.mercurial-scm.org/D8973 has been approved.
But, I have not seen it land in the maintainer's repo at https://www.mercurial-scm.org/repo/hg or even at https://www.mercurial-scm.org/repo/hg-committed/ ...

I was a bit disappointed. Was my patch series silently put to rest, behind the curtain ?

Deduplication

Mercurial has a fancy format called "Bundle" for the wire protocol. But, the .hg/store does not use "Bundle", and the result is that if you add 10 files with the same content to a Mercurial repository, the Mercurial object store will have 10 copies of it. There is no deduplication. Git has deduplication (since day one) which does the right thing of not storing 10 objects with the same content. Linus Torvalds calls that a content-addressable store.

Conclusion

To me, Mercurial is a dinosaur software. It does not evolve, and is going extinct.

At least, the third DVCS, Fossil, acknowledges what it wants to be in its name !

Comments

Popular posts from this blog

Changing the capacity of each VDEV in a ZPOOL without losing data and no downtime with ZFS

A new beginning in computational geometry

Adding ZVOL VIRTIO disks to a guest running on a host with the FreeBSD BHYVE hypervisor