[mystickphoenix]

I suppose what I'm looking for is maybe a translation from git to jj from the perspective of working in a repo with other users that are using git. Something along the lines of:

1. init jj in an existing git repo

2. instead of branching, do x, y, z

3. instead of committing after changes are done, do x, y, z

4. when pushing, do x, y, z

5. if someone else pushes to the same branch, here's how to handle it

6. if someone rebases and force pushes the branch, here's how to handle it

7. if you have merge conflicts, here's how to handle that

I think I'm having a hard time trying to grok the jj "mental model" while simultaneously understanding how it translates to an existing git repo.

I suspect for jj to get traction outside of single devs or companies that use jj exclusively, some extra focus in the docs giving guidance in the liminal space between would be super helpful.

[steveklabnik]

Ahh, I see, thanks.

> some extra focus in the docs giving guidance in the liminal space between would be super helpful.

I'm working on this! https://steveklabnik.github.io/jujutsu-tutorial/real-world-w... describes the most basic two workflows for 2-3. https://steveklabnik.github.io/jujutsu-tutorial/sharing-code... tries to explain 4-6 (but isn't as complete as it should be), and there's an unwritten place for 7 to exist in the future.

I don't think these things are perfect yet, and I'm actually re-writing the whole thing, and it's going to focus on exactly these things, and there's interest in upstreaming the whole thing. That is partially why I asked, because I'm trying to make it so that these things are more easy for you in the future :) So I do really appreciate the answer.

[mystickphoenix]

Just wanted to say thank you for working on this, I'm going to take another read-through of those 2 links and see if it makes more sense given the extra context of this thread. Either way, I look forward to reading the updates and seeing if they click better in my brainpan ;)