Cherry picking is just convenience for something that anyone could do manually. If it didn't exist in the VCS, people would do it anyway and make tools to do it.
Fossil's implementation is the best, since a cherry-picked commit always points back to its origin.
Speaking as a former Darcs user (Darcs is another patch-based VCS that Pijul draws inspiration from):
"This is a useless property because the graph is only encoded at the patch layer. In the real world you have far more semantic dependencies than patch dependencies. ie, I have a patch that adds a function that calls a function added in another patch. Pijul doesn't know about that."
Darcs solved this in two different ways.
1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.
2. Practicality. In reality, there's no scenario where someone is pulling your "use function X" patches and also not pulling the "define function X" patch. They could if they really want to, but this would be a lot of effort for a deliberately bad result. It would be like, in Git, cherry-picking the "use" patches without the "define" patches. In neither system would this happen by accident.
"Conflicts coming back is not an issue in git. For some reason people think they need to use rebase when they should almost always be using merge."
There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.
I deliberately moved away from Darcs after a few years - the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened. (Also branch discovery in Darcs basically doesn't exist; Pijul fixed this, at least!) I love Fossil and Mercurial for their adherence to accurate history.
What I want is a system that records how conflicts are resolved and tries to apply that resolve. Lets say I have apply patch A, then patch B, there is a conflict, I resolve it. Then someone else applies patch B and then patch A. The VCS should know that this conflict is already resolve and apply the solution. Likewise when applying first patch C, then A and B, it should let you resolve the conflict from AB to ABC and again record the resolved conflict for the future. I'm actually fine with manually resolving conflicts, but don't want to it twice if I don't have to. This would be a great way to organize something like dwm, but I couldn't get it to work with pijul at all.
> 1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.
I don't know who would want to put in the work of mapping out the semantic dependency graph because maybe some day someone might want to compose a slightly different set of patches. And even if everyone tried, it would surely still fail because that's so hard or impossible.
> There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.
Just stop using rebase is much easier to socialize than let's all move to Pijul. It's also the correct thing to do.
> the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened.
I strongly agree with this and think it's the only tractable way to operate.
There are downsides to both formats, but with paper there's no company keeping track of the date/time I open the books on my selves, or how often I open them, or how long I spend on each page, or how long I take to read the whole thing. I also don't have to worry about the books on my shelves being remotely and silently censored or edited. I don't have to worry about ads being inserted into them and I can freely read them and sell/loan them to others long after they've been banned.
The be fair the parent said "almost." I see this more as a backup of the physical book. Other than search, the experience of physical books is superior, I think, for most people for most uses. You can come up with counterexamples like certain aspects of studying textbooks, etc., but I think this is true in general.
Can most people get physical books? Ebooks are made freely accessible by projects like Anna's Archive. An ebook can be more easily used as a printing source, can be more easily cited in research, and can be better preserved.
The one advantage of physical books is the reading experience itself, but even that is debatable. A Kindle lets you adjust brightness, change fonts—there are fonts that help dyslexic people, for example—and it's lighter than books. Did I mention dark mode?
First, let me step on my own foot for the sake of accuracy: people retain information slightly better when they read paper than screens, so textbooks definitely aren't an example I'd go with. https://pmc.ncbi.nlm.nih.gov/articles/PMC8715975/
That said, I can come up with far more than a few counterexamples for why ebooks are good, besides combustability:
- Paper books are dense. This adds difficulty to moving and maintaining large collections.
- Paper books take up space. Bookstores and libraries must necessarily remove books to make space for new ones. With ebooks, there's basically no need to remove old ones.
- Paper books are dense and take up space, so when travelling, the reader must carefully select one or two to carry. With ebooks, I can carry my entire ebook library in my pocket.
- Paper books require more effort to duplicate. My e-library is replicated across many devices, including two different offsites. If I spill sauce on a paper book, I need to buy another copy (assuming it's still available).
- Paper books have accessibility issues. As I get older and my vision deteriorates, I will need specialized optical hardware to read small print. On my e-reader, I can just turn up the font size.
In spite of all this, I would never say that ebooks are objectively superior; both are good. I just take issue with all of the people who assume that physical books are so obviously inherently superior, without ever saying why. (See your own post for example.)
I buy "licenses" to read DRM'd ebooks all the time. Even though I disagree with DRM, I still want to reward the author/editor/illustrator/translator/etc for their artistry.
As for whether I leave the books in their DRM'd state or not? No comment :)
I thought this too for a long time. But I have since raised my estimate of the harms of DRM, and lowered my estimate of how much entertainment these artifacts provide. There is enough to read now without putting up with abusive relationships.
"Reading on a E-device is a bother, I have to sift through all the "sponsored" books and whatever other crap the ebook reader company decides to add, and be at the whims of whatever they decide they want to do with "your" device that day."
My fellow, you are on Hacker News. Think like a hacker, not a consumer.
Plenty of savvy e-book customers here don't have the experience you just described. Look up how to put KOReader ( https://koreader.rocks ) on your current device, and learn how to get your books without DRM. Your e-reading experience will be so much better.
1-based indexing is great. It's just _different_ - from C, where the array index is just sugar for pointer arithmetic, and from other languages which borrowed the practice without reasoning.
> we had better regard —after all those centuries!— zero as a most natural number
Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.
To be honest, I actually agree that Dijkstra's argument seem a bit one sided. It's also interesting to see the argument in your linked article that offset and index doesn't have to be the same.
If I get the root of the argument in the linked article, it is that zero-based indexing is more of a optimization than anything, but I would disagree; there are reasons beyond that (see the examples in my previous comment).
Also, here's an example of an 1-index based system that has caused me some headaches: In music theory, the first note of the scale is called the "first", etc. It also talks about e.g. "stacking thirds", which means take the third of the scale, than take the third from there. However, the offsets are two. (first=offset 0, second=offset 1, third=offset 2). Which is hard to work with in my opinion.
You have an interesting argument about iterating backwards, although I would say; if we need a tie-breaker between the two, iterating forward should have more weight than backwards.
I appreciate your comment, and while trying as best I can to be convinced of the "other side", I still land on 0-indexing. The only argument I buy, is that it matches our natural language starting at 1. Which, of course, is a strong argument.
The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.
I cannot fathom why anyone would use a code freeze. Just create a branch at the commit you want to "freeze" and let dev teams keep working with their regular branches.
Fossil's implementation is the best, since a cherry-picked commit always points back to its origin.
reply