4 ms·

> So does anyone who's ever used Mercurial, for that matter. So I've used mercurial and git in production. The one thing that turned me off on mercurial was t

by bb88 6y ago

> So does anyone who's ever used Mercurial, for that matter. So I've used mercurial and git in production. The one thing that turned me off on mercurial was that branching information was stored as part of the commit. This led sometimes to weird conflicts where the branch list needed to be merged. Granted that's been several years ago, so it might be different now, I don't know, and with git I have no need to. I definitely appreciate branching data being meta data outside of the branch. Also Darcs had severe issues maybe a decade ago where merging would appear to cause infinite locking. It wasn't a coding bug, it was due to their originally flawed theory of patches. So while it may be awesome, the world has definitely moved on. It's worth reading this from pijul: > Did you solve the “exponential merge problem” darcs has? > Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future. So good, but polynomial time can still be large beasts computationally.

pmeunier 6y ago
Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.
- bb88 6y ago
  I was worried it was larger than n^2. Thanks for clarifying.
iggldiggl 6y ago
I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too. Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.

by bb88 6y ago

pmeunier 6y ago

Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.

bb88 6y ago
I was worried it was larger than n^2. Thanks for clarifying.

iggldiggl 6y ago

I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too. Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.