grim_io
a day ago
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.
joshka
21 hours ago
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...
tinodb
12 hours ago
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
10 hours ago
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
7 hours ago
Sounds like "git reset" to me. Not sure, if it is, but this sounds to be easier in git.
martinvonz
6 hours ago
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
6 hours ago
> `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 @
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.
martinvonz
6 hours ago
Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.
1718627440
5 hours ago
> `git reset` by itself doesn't split a commit AFAIK.
Git reset splits a single commit, into two "things", another commit with the first part and a second part that is put into a version prepared for a commit (--soft), prepared for further editing (--mixed) or thrown away (--hard). To me that counts as commit splitting, but it may not match with JJ terms. Also splitting into two commits with the same commit message doesn't sound quite useful to me, so the default of Git two require a second commit message is sensible to me.
> Those were rhetorical questions.
Ok, but then what was your point?
martinvonz
3 hours ago
> To me that counts as commit splitting
Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. That will move the current branch backwards one step. With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD) and the working copy has the combination of changes that were in the previous HEAD commit and the working copy (relative to the previous HEAD). I think that's more like squashing than splitting because we have fewer "things" after: we have one commit fewer (the previous HEAD commit may of course still be reachable from another branch, in which case we still have the same number of "things" afterwards). It's similar with `--soft` and `--hard`, except that the old changes end up in a different "thing".
At a less technical level, the point of splitting a commit is to end up with some of the changes from one commit in a new commit and the rest of the changes in another commit. That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:
git reset HEAD^
git add -p
git commit -C HEAD@{1}
Just that additional steps are needed.
For example, if you wanted to split the HEAD commit but you had already started working on a new commit so have some changes in the working copy, then you might instead have to do something like this:
git commit -m tmp
git rebase -i HEAD^^ # Use the "edit" action for the first commit
git add -p
git commit -m first
git rebase --continue
git reset HEAD^
(Take my Git commands with a grain of salt because I haven't used Git in 10 years.)
benoitg
20 hours ago
I’m the same as the parent, auto-track = none() works perfectly for me
jauntywundrkind
21 hours ago
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
17 hours ago
> 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.