5 ms·
Because a thing that programmers tend to call "design" directly impacts how a user is able to interact with the tooling, obviously? Are you seriously asking "Ho
by aseipp 7y ago
Because a thing that programmers tend to call "design" directly impacts how a user is able to interact with the tooling, obviously? Are you seriously asking "How could a thing like 'core design of the system' ever impact how someone uses it?" or are you just trolling for the sake of it?
As a real example, I used to be the maintainer of a major project that had long running stable branches. This means I needed to often cherry pick bugfixes from one place to another, but cherry picks are often difficult because they can rely on prior changes you haven't yet picked. In a system like Git, you have to cherry pick things in chronological order in order to replicate each "snapshot" of the history that the original changes came from, so the merge algorithm can figure it out. What change do you start from? Who knows! You have to find the first change that can be merged properly, or by hand, and work your way from there. You effectively have to hold the hand of the tool in cases like this.
In systems like Darcs or Pijul, that does not happen. They are always able to keep track of dependencies between patches, and so a "cherry pick" naturally implies picking change A, and all dependencies of A that are not yet available. There is no notion of having to run multiple commands or whatever; it's completely transparent. From there you can either A) accept the dependent changes or B) do surgery, for example, if you need to more carefully backport things. A) is the common case in the vast majority of uses, in my experience. Where as in Git, after a long enough time, almost any uses of 'cherry pick' will immediately fail and require you to start digging and picking out historical changes -- in Darcs, it will keep working just fine, even for dozens or a hundred dependent changes you need. The default features of the tool and their UX matter a lot, here.
If you not only can't understand how different core design choices -- like the ones in Pijul or Darcs -- can impact how a user uses a tool, but even refuse to admit that a tool could ever be used any other way: that alone is a great indictment of Git's complete and total monoculture, and precisely why these tools need to keep existing. Then again, computer programmers love having stockholm syndrome and hate reading things, so maybe it doesn't matter.
Here is a good, short video explaining the theoretical underpinning of Darcs and how they impact the user (and an old side project, "Camp", that was planned to eventually become Darcs 3). It's over a decade old and just as relevant as it ever was: https://www.youtube.com/watch?v=iOGmwA5yBn0 https://www.youtube.com/watch?v=iOGmwA5yBn0
- atq2119 7y agoOn cherry-pick dependencies: there is no way that any VCS can solve that problem for you, because dependencies can be (and often are, for the projects I've worked on) non-local. That is, you can have a dependency even though the changes appear to be unrelated from a textual point of view. I'm all for developing better tooling for digging into blame-history, which is more generally useful and would cover the textual dependencies between changes, but you shouldn't believe that that solves the dependency problem.
- pmeunier 7y ago> but you shouldn't believe that that solves the dependency problem. I don't think anyone believes that. The dependencies in Pijul are the minimal dependencies that make the patch application possible, they are by no means semantic (you can totally add dependencies manually, btw). However, for the particular use case explained above (stable branches, backporting bugs), the default behaviour of Pijul already gives you something really useful.
- atq2119 7y agoRight. I guess what I'm trying to say is that this isn't anything truly fundamental about Pijul. You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git. The fact that this particular feature already exist in Pijul is not a great argument for changing the underlying data structure, which is what switching to another DVCS is.
- pmeunier 7y ago> You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git. Absolutely, the only difference is the time you'll waste managing your branches (creating, rebasing and merging them).