[grim_io]

I tried jj a few times but it seems to be incompatible with my workflow.

I tend to have lots of uncommitted files and changes that i want to keep around in this state while I move around branches and while having multiple change lists (jetbrains implementation) that I will commit at some point in time.

This loose, flexible way of using git seems hard to do in jj.

[jauntywundrkind]

I'd been concerned about that initially, but setting up some gitgnores made this a complete non problem for me. .scratch/ for a lot, *.scratch, and ig-*.

It's also so easy to go back to the change latter and remove the files (after they're already copied elsewhere, or just operations log to go get) that it's really not a problem to just let stuff get in your commits.

In git there's such a strong incentive to do things right, to make clean commits. Imo one of the huge strengths of JJ is abandoning the obsession, and having far far far better tools to clean up after.

[skydhash]

> In git there's such a strong incentive to do things right, to make clean commits.

There is no such. There are a lot of tools to manipulate commits and WIP, such as the stash, rebase, cherry pick, extracting and applying patch. You only need clean commits for review and the main branch because that helps the whole team. Your local copy can be as messy as you want to.

[jauntywundrkind]

The incentive for me is just that it's not the most fun to use git's rebase tools to move things between commits. I'm pretty OK at rebase, but I still would way way rather not try to rebase move a file from one commit to another. And if I did, I'd probably do something hacky to copy the file out rather than try to use git to checkout the file from a rev.

Where-as jj makes rework operations, IMO, basically easy enough (after a couple weeks of use to) that I worry much less about making the right commit the first time.

[joshka]

Some techniques for this are covered in: https://docs.jj-vcs.dev/latest/FAQ/#how-can-i-keep-my-scratc... and https://docs.jj-vcs.dev/latest/FAQ/#how-can-i-avoid-committi...

[benoitg]

I’m the same as the parent, auto-track = none() works perfectly for me

[tinodb]

The work needed for the “I included something in a commit I want split out” [0] seems really complex, and it is something I do often.

Eg with stacked git (stg) this is just: goto, spill, and then refresh/create the stuff I want.

[0] https://docs.jj-vcs.dev/latest/faq/#i-accidentally-changed-f...

[martinvonz]

You can do that with just `jj split` too. The FAQ entry you linked to is for when you accidentally amended a commit and now you want to restore the bookmark to the old commit and move the changes you amended into a new commit on top instead.

[1718627440]

Sounds like "git reset" to me. Not sure, if it is, but this sounds to be easier in git.

[martinvonz]

I have used both Git and jj. I find it easier in jj.

`git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit` (and recover the commit message from the old commit). And what happens if you had other changes in the working copy first? Or if you want to split a commit that's not at HEAD?

[1718627440]

> `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit`

If you want to generate two commits with the exact same message, then do:

    git checkout combined-commit
    git reset --soft previous-version
    git commit -C @

> And what happens if you had other changes in the working copy first?

Do something with them. Put them in a commit, put them into a commit in the global stack of todo commits or tell git to do that automatically.

> Or if you want to split a commit that's not at HEAD?

Check it out or do a rebase.