4 ms·

Related: it's been a year since Pijul (https://pijul.org https://pijul.org) began working towards 1.0 (https://news.ycombinator.com/item?id=25032956 https://new

Related: it's been a year since Pijul (https://pijul.org https://pijul.org) began working towards 1.0 (https://news.ycombinator.com/item?id=25032956 https://news.ycombinator.com/item?id=25032956). Seems to be coming along nicely, they're in alpha now and it's showing.

kadoban 5y ago
I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.
- martinvonz 5y ago
  If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. It has git interop.
  - IshKebab 5y ago
    That looks very cool, and very wise to use git as the actual storage system. Means you have a chance of people actually using it. I have one question: how do changes to files in the working copy automatically update the current commit hash? Do you just calculate it on demand, and then actually make the commit when some command would move to different commit (`jj switch someotherbranch` or whatever)?
    - martinvonz 5y ago
      Any command that depends on the working copy commit will first check if it needs to create a new commit from the working copy contents. So when you run e.g. `jj status`, it will amend the current working copy commit if there are changes. In case you're thinking that that seems slow, it's not really significant at least up to git.git scale. For larger repos, I plan to rely on something like watchman.
  - kadoban 5y ago
    Thanks, I'll check it out. Yeah, that's the main draw for me.
- pmeunier 5y ago
  First, you can easily import Git repos into Pijul. One issue with two-way interop is that while importing a commit into a patch is easy, doing the opposite is more complicated. Indeed, since Pijul is patch-based, there is no way to map patches onto commits in a unique way, since a single patch is quite independent from the context (other patches around it), which is what makes Pijul easy to use. Also, if Alice and Bob work on a common Pijul server in parallel with their Git server, they'll get artificial conflicts in Pijul, even though they have the same contents.
  - kadoban 5y ago
    I just want to be able to use pijul myself, locally. So I'd want it to just arbitrarily choose a mapping of patches to commits, like by timestamp I guess?
    - pmeunier 5y ago
      That could work. If your local patches are complex enough you could even rearrange them using patch commutation. At the moment, Pijul is in a state where there is just one remaining feature I want to implement before beta, with a massive expected impact on disk space (and a limited impact on speed as well). For the kind of "smaller (but essential) features" like what you're suggestion, there are tons of those, and we can totally implement them after beta. Git export is a common request we get, though. I'm just scared of how people will react when they export and then reimport their patches elsewhere, and get tons of fake conflicts.
      - kadoban 5y ago
        I think you will get a lot of complaints, which is unfortunate, but many many will understand that it's not going to be perfect. I was there for the period of switching from svn to git, and similar things happened. Really the only way I even learned git itself is because I could use git locally and the rest of my team couldn't tell. Regardless though, pijul is really cool. I just badly want to be able to use it at my day job :)
      - renox 5y ago

kadoban 5y ago

I keep checking in on that. In my case what I need to start seriously using it is two-way git interop. I need to be able to work in pijul locally and "publish" somehow to git. So far that still doesn't seem to exist.

martinvonz 5y ago
If the Pijul feature you care most about is "first-class conflicts", you may want to check out my VCS: https://github.com/martinvonz/jj https://github.com/martinvonz/jj. It has git interop.
- IshKebab 5y ago
  That looks very cool, and very wise to use git as the actual storage system. Means you have a chance of people actually using it. I have one question: how do changes to files in the working copy automatically update the current commit hash? Do you just calculate it on demand, and then actually make the commit when some command would move to different commit (`jj switch someotherbranch` or whatever)?
  - martinvonz 5y ago
    Any command that depends on the working copy commit will first check if it needs to create a new commit from the working copy contents. So when you run e.g. `jj status`, it will amend the current working copy commit if there are changes. In case you're thinking that that seems slow, it's not really significant at least up to git.git scale. For larger repos, I plan to rely on something like watchman.
- kadoban 5y ago
  Thanks, I'll check it out. Yeah, that's the main draw for me.
pmeunier 5y ago
First, you can easily import Git repos into Pijul. One issue with two-way interop is that while importing a commit into a patch is easy, doing the opposite is more complicated. Indeed, since Pijul is patch-based, there is no way to map patches onto commits in a unique way, since a single patch is quite independent from the context (other patches around it), which is what makes Pijul easy to use. Also, if Alice and Bob work on a common Pijul server in parallel with their Git server, they'll get artificial conflicts in Pijul, even though they have the same contents.
- kadoban 5y ago
  I just want to be able to use pijul myself, locally. So I'd want it to just arbitrarily choose a mapping of patches to commits, like by timestamp I guess?
  - pmeunier 5y ago
    That could work. If your local patches are complex enough you could even rearrange them using patch commutation. At the moment, Pijul is in a state where there is just one remaining feature I want to implement before beta, with a massive expected impact on disk space (and a limited impact on speed as well). For the kind of "smaller (but essential) features" like what you're suggestion, there are tons of those, and we can totally implement them after beta. Git export is a common request we get, though. I'm just scared of how people will react when they export and then reimport their patches elsewhere, and get tons of fake conflicts.
    - kadoban 5y ago
      I think you will get a lot of complaints, which is unfortunate, but many many will understand that it's not going to be perfect. I was there for the period of switching from svn to git, and similar things happened. Really the only way I even learned git itself is because I could use git locally and the rest of my team couldn't tell. Regardless though, pijul is really cool. I just badly want to be able to use it at my day job :)
    - renox 5y ago