3 ms·

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

by 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?

by dilap 7y ago

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?