3 ms·

The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting

by arunc 9y ago

The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting solution. If hg supports to strip a remote repo, it would be just fantastic! hg evolve is awesome and topics are fantastic, but a `hg strip <remote-url>` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!

gmueckl 9y ago
Could that be added as an extension? I don't know how extensions can work with remotes.
rbehrends 9y ago
1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological order. Stripping a branch means first saving all commits that are not being stripped (but occur chronologically after the first stripped commit) to a bundle, then truncating the revlog before the first stripped commit, then restoring the commits from the bundle. This can already be an expensive operation locally, but it's even more of a problem on a server shared by multiple users who may have been pushing their own commits. 2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users. 3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.

3 ms·

The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting

by arunc 9y ago

gmueckl 9y ago
Could that be added as an extension? I don't know how extensions can work with remotes.
rbehrends 9y ago
1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological order. Stripping a branch means first saving all commits that are not being stripped (but occur chronologically after the first stripped commit) to a bundle, then truncating the revlog before the first stripped commit, then restoring the commits from the bundle. This can already be an expensive operation locally, but it's even more of a problem on a server shared by multiple users who may have been pushing their own commits. 2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users. 3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.