3 ms·
On 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 work
by atq2119 7y ago
On 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).