4 ms·

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer re

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)

davidkunz 1y ago
What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
- steveklabnik 1y ago
  Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
  - antonchekhov 1y ago
    I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
    - steveklabnik 1y ago
      I'm a big CLI for VCS person, so yeah, I use those tools too :)
- ElectricalUnion 1y ago
  So you want Fossil?
  - arccy 1y ago
    except fossil decided to never allow changing history, vs jj which makes history rewriting so much easier
    - 1313ed01 1y ago
      That's my favourite thing about fossil though. History is what it is, not simplified to look "clean" (i.e. hide what actually happened and when) and you get a lot fewer footguns to ruin everything by accidentally rebasing things to the wrong place without noticing.
  - anotherevan 1y ago
    When I tried Fossil it had things weirdly separated. I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
gravypod 1y ago
I would love having some first class support for monorepos at bigger organizations (ex: silos, vfs, etc).
- steveklabnik 1y ago
  No promises but noted for sure…
saulrh 1y ago
If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.
codethief 1y ago
> we have to offer real value here If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC. EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335 https://news.ycombinator.com/item?id=45675335
- steveklabnik 1y ago
  This is something that I am comfortable saying is absolutely going to be the case.
  - codethief 1y ago
    That's great to hear! Looking forward to ERSC!

davidkunz 1y ago

What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation

steveklabnik 1y ago
Noted :) In another comment I linked to beads, which is a cool project to keep your issue tracker in your repo, but that's just a personal thing, no comment on what the company plans to do (or not) in this area.
- antonchekhov 1y ago
  I use command-line tooling much more than IDEs (e.g. VS Code), so the `gh` command-line tool (https://cli.github.com https://cli.github.com) for doing most of the usual hub-oriented workflow (PR authoring, viewing issues, status updates, etc) really helps a lot - I don't have to constantly <cmd>+<tab> to my browser, and point-click-point-click through web pages so much. It would be fantastic if ersc or any other jj-centered code-sharing hub had similar tooling early on.
  - steveklabnik 1y ago
    I'm a big CLI for VCS person, so yeah, I use those tools too :)
ElectricalUnion 1y ago
So you want Fossil?
- arccy 1y ago
  except fossil decided to never allow changing history, vs jj which makes history rewriting so much easier
  - 1313ed01 1y ago
    That's my favourite thing about fossil though. History is what it is, not simplified to look "clean" (i.e. hide what actually happened and when) and you get a lot fewer footguns to ruin everything by accidentally rebasing things to the wrong place without noticing.
- anotherevan 1y ago
  When I tried Fossil it had things weirdly separated. I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.

gravypod 1y ago

I would love having some first class support for monorepos at bigger organizations (ex: silos, vfs, etc).

steveklabnik 1y ago
No promises but noted for sure…

saulrh 1y ago

If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.

codethief 1y ago

> we have to offer real value here If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC. EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335 https://news.ycombinator.com/item?id=45675335

steveklabnik 1y ago
This is something that I am comfortable saying is absolutely going to be the case.
- codethief 1y ago
  That's great to hear! Looking forward to ERSC!