diff flow without index

[ghost]

I see that JJ has no index:

https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md

I am OK with that, but I am wondering how to adapt my current flow. usually with Git, a commit will involve multiple files. so when preparing a commit, I will:

1. git diff
2. once I confirm a specific file is OK, then git add file
3. loop back to step 1 until all files are done, OR maybe just commit some of the files only

the benefit of this is that as I make progress, the diff gets smaller. does JJ have some similar workflow to this?

[ilyagr]

Could I ask you to be a guinea pig for our new FAQ? See https://github.com/martinvonz/jj/blob/main/docs/FAQ.md#can-i-prevent-jujutsu-from-recording-my-unfinished-work-im-not-ready-to-commit-it.

Let me know if it helps, and feel very welcome to ask follow-up questions, especially if it doesn't address your question (but also in any case).

[ghost]

thanks for all the responses. hopefully they will help future readers as well. I guess this tool is just not for me. maybe I will understand it better one day. I know people complain about the index, but it seems quite useful to me. its a simple and elegant way to say "here is something that is partially done" while a commit is a way to say "this is done", and the working directory changes are "not done". JJ seems to say:

everything is a commit and everything is done, but if you're not actually done you need to go back and fix what was not done, and the tooling will not provide an integrated way to delineate "done" from "not done" work, so you'll need to just come up with a best practice.

[arxanas]

everything is a commit and everything is done, but if you're not actually done you need to go back and fix what was not done, and the tooling will not provide an integrated way to delineate "done" from "not done" work, so you'll need to just come up with a best practice.

That sounds about right 😇. I will let you know if jj adopts Mercurial-style phases, because they might solve your problem.

It wasn't mentioned in this thread, but it's probably worth providing this context: I think most jj users use a heavily patch-based workflow, where we will submit multiple commits for review and, based on code review feedback, go back and amend them until they pass review. In this sense, the commits we're working on are never necessarily "done". Maybe that's why we don't have an emphasis on "done"/"partially-done"/"not done" phases — because no local work is ever "done". Usually it's only "done" when it gets merged into an upstream branch (at which point we won't amend/rewrite it because it's public history).

[martinvonz]

• A commit message starting with e.g. wip:. means that it's "partially done".

thats what I was afraid of. this just seems like re-inventing the index, using an idiom instead of an integrated part of the tool. so it appears that the index was removed, but people are still using it in an ad hoc way. I prefer to just use a tool that supports it properly, so maybe JJ is not right for me.

At least the way I work, there are often commits that I'm working on that are not yet ready to send for review yet. I often give these a message, but I suspect I'm not as consistent as @arxanas about prefixing them with "wip:". But the point is that I would have these commits when using Git too. Don't you? If you don't, then what do you do when you need to switch tasks for a while? I usually have tens of commits of unfinished work.

[martinvonz]

I guess this tool is just not for me. maybe I will understand it better one day.

It's definitely meant to be useful for your workflow. I think part of it is about getting over the fact that the working copy gets automatically committed and not thinking that that means that it has to be "done". And where you currently build up the index by incrementally adding file with git add, you'd instead do that by incrementally growing a commit. After making some changes in the working copy and you feel ready to build up a "real/done" commit, you'd run jj split <file> (or just jj split to interactively select changes) to move some changes into a new commit. Then you can jj squash/amend ([-i] | <files>) to add more changes into that commit, just like you would have used git add ([-p] | <files>).

If we wanted an index like git's index, we could do that by treating the working-copy commit's parent differently. We could highlight it in the log output, for example (I think gitk shows the index as a green dot and the working copy as a red dot, or at least it did that ~12 years ago). It wouldn't be hard to implement that, but I think it's much better to not treat the working-copy commit's parent specially.

I know people complain about the index, but it seems quite useful to me. its a simple and elegant way to say "here is something that is partially done" while a commit is a way to say "this is done", and the working directory changes are "not done".

JJ seems to say:

everything is a commit

Yes.

and everything is done

No, that's up to you to keep track of.

, but if you're not actually done you need to go back and fix what was not done, and the tooling will not provide an integrated way to delineate "done" from "not done" work, so you'll need to just come up with a best practice.

I personally consider pretty much every commit that's not in a PR unfinished. Even if we had a command to mark a commit as "done", I would probably just send it for review when it was done anyway, so "marked done" and "is part of PR" would probably almost always go hand in hand.

[joyously]

From what I can discern, the OP values the way that Git's diff gets smaller as each file is staged, providing a way to keep track of what is recorded and what is not.
Jj would show a smaller diff as each commit is moved out of the working copy commit, wouldn't it?
I would suggest that perhaps it's a good thing to keep fewer changes uncommitted, which is what jj does for you.

[martinvonz]

I see that JJ has no index:

https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md

I am OK with that, but I am wondering how to adapt my current flow. usually with Git, a commit will involve multiple files. so when preparing a commit, I will:

1. git diff
2. once I confirm a specific file is OK, then git add file
3. loop back to step 1 until all files are done, OR maybe just commit some of the files only

the benefit of this is that as I make progress, the diff gets smaller. does JJ have some similar workflow to this?

Just to make sure, did you see https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index? Because the second paragraph there was meant to describe exactly your workflow (as far as I understand it anyway). If you missed that section, we should see how we can clarify it.

[tp-woven]

Reading that section now, I wonder if it would be useful to also mention that you can jj squash <file>, as it's more similar to git add <file>? 🤔

[martinvonz]

That would make sense to me.