4 ms·

> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by

> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. At best, the argument made by Pijul's backers is that Pijul implements this feature differently and in a way that arguably may be creating a problem where in Git there is none.

pmeunier 7y ago
> The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.
- rumanator 7y ago
  There is a clear argument that you chose to ignore: cherry-picks are patently not a problem in Git, and the only problematic aspect is how some git users might create their own personal problems by developing misinformed workflows while ignoring any information on best practices. If you try to reinvent the wheel on your own, ignore any advice or info, and end up with a badly shaped polygonal thing then you simply can't pin the blame on your chisel.
  - afiori 7y ago
    A lot of the criticism git receive is about the stance that there is the git way and the wrong way. We all are super sure that git has extremely efficient workflows available; it is just that maybe many people do not like them. Git does not try to be a tool for everyone; it is very opinionated on how to best use it; this obviously leaves space for less opinionated tools or even differently opinionated tools to shine under specific use cases/scenario
dilap 7y ago
Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev <-> release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.
- rumanator 7y ago
  I guess it's a matter of personal opinion but as a git and svn user I simply fail to see any relevance or value in Pijul's selling point regarding cherry picking. It feels that the argument for Pijul starts from a problem that never existed, and even so the selling points fail to present a case for the alternative. And to be honest, if the worse pain point of git that the Pijul team addressed was git's cherry-picking, it looks like they failed to do any form of cursory homework on Git. But hey, just my 0.02€. Everyone should use the tools that they prefer, and if someone has a problem with Git cherry-pick that they feel is better solved by switching tooling instead of reviewing the problems then have fun.
  - pmeunier 7y ago
    I think you've failed to read the other answers I and others have provided. But hey, everyone should read the answers they want, if someone wants to pick only the ones that are the easiest to dismiss then have fun.
    - rumanator 7y ago
      > I think you've failed to read the other answers I and others have provided. I read them and it was based on those comments, and also the half a dozen previous discussions on Pijul here at HN, that I formed my opinion.
  - hibbelig 7y ago
    Let me try to present one problem relating to cherry-picking. I don't know Pijul so I'm not sure it illustrates its strength clearly, but at the very least it should address the idea that there is no problem with cherry-picking. Using git terminology here. Say you have a release branch and a master branch, and you normally fix bugs on the release branch and then merge the release branch into master. Now it happens that a bug was fixed in master, and later it turns out that it's actually a critical thing that should be fixed on the release branch, too. So you cherry-pick that fix into the release branch. Now the next time you merge from release into master, you attempt to merge this commit that was originally cherry-picked from master, so it's already present in master. But git doesn't know. With some luck, git sees that the textual change is already present, but I believe that can also fail sometimes. With Pijul, you would have applied the patch from the release branch onto the master branch, and Pijul would have recorded that, and on the next merge from release to master, Pijul knows to skip this patch. Another place where Pijul helps is when cherry-picking the bugfix in the first place: Suppose the bugfix includes calling some function (procedure, method), but another (earlier) change on master has renamed that function. Then Pijul can alert you to this fact and tell you which other commit (patch) from master is needed to cleanly apply the bugfix. Does this help?

pmeunier 7y ago

> The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.

rumanator 7y ago
There is a clear argument that you chose to ignore: cherry-picks are patently not a problem in Git, and the only problematic aspect is how some git users might create their own personal problems by developing misinformed workflows while ignoring any information on best practices. If you try to reinvent the wheel on your own, ignore any advice or info, and end up with a badly shaped polygonal thing then you simply can't pin the blame on your chisel.
- afiori 7y ago
  A lot of the criticism git receive is about the stance that there is the git way and the wrong way. We all are super sure that git has extremely efficient workflows available; it is just that maybe many people do not like them. Git does not try to be a tool for everyone; it is very opinionated on how to best use it; this obviously leaves space for less opinionated tools or even differently opinionated tools to shine under specific use cases/scenario

dilap 7y ago

Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev <-> release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.

rumanator 7y ago
I guess it's a matter of personal opinion but as a git and svn user I simply fail to see any relevance or value in Pijul's selling point regarding cherry picking. It feels that the argument for Pijul starts from a problem that never existed, and even so the selling points fail to present a case for the alternative. And to be honest, if the worse pain point of git that the Pijul team addressed was git's cherry-picking, it looks like they failed to do any form of cursory homework on Git. But hey, just my 0.02€. Everyone should use the tools that they prefer, and if someone has a problem with Git cherry-pick that they feel is better solved by switching tooling instead of reviewing the problems then have fun.
- pmeunier 7y ago
  I think you've failed to read the other answers I and others have provided. But hey, everyone should read the answers they want, if someone wants to pick only the ones that are the easiest to dismiss then have fun.
  - rumanator 7y ago
    > I think you've failed to read the other answers I and others have provided. I read them and it was based on those comments, and also the half a dozen previous discussions on Pijul here at HN, that I formed my opinion.
- hibbelig 7y ago
  Let me try to present one problem relating to cherry-picking. I don't know Pijul so I'm not sure it illustrates its strength clearly, but at the very least it should address the idea that there is no problem with cherry-picking. Using git terminology here. Say you have a release branch and a master branch, and you normally fix bugs on the release branch and then merge the release branch into master. Now it happens that a bug was fixed in master, and later it turns out that it's actually a critical thing that should be fixed on the release branch, too. So you cherry-pick that fix into the release branch. Now the next time you merge from release into master, you attempt to merge this commit that was originally cherry-picked from master, so it's already present in master. But git doesn't know. With some luck, git sees that the textual change is already present, but I believe that can also fail sometimes. With Pijul, you would have applied the patch from the release branch onto the master branch, and Pijul would have recorded that, and on the next merge from release to master, Pijul knows to skip this patch. Another place where Pijul helps is when cherry-picking the bugfix in the first place: Suppose the bugfix includes calling some function (procedure, method), but another (earlier) change on master has renamed that function. Then Pijul can alert you to this fact and tell you which other commit (patch) from master is needed to cleanly apply the bugfix. Does this help?