[sundarurfriend]

The biggest blocker for me to switch to using jj currently is https://github.com/jj-vcs/jj/issues/3949 which is that it doesn't have a `core.fileMode` option equivalent. What this means in practice is that it's unusable from WSL when your repo is on an NTFS filesystem. It gets confused by NTFS's lack of executable permission bit and makes spurious changes/commits.

It's a small thing, but while jj adds some convenience, it doesn't add enough (for me) to offset the inconvenience of changing my workflow to not use WSL. (Another relatively minor inconvenience is its inability to use your SSH configs. So if you have multiple key pairs and need to use specific ones that aren't jj's default pick, an ssh-agent is the only way.)

That said, I would 100% recommend jj over git for any new programmer who hasn't yet had to contort their brain already into the git ways. All the things that git's UI does a great job of obscuring and presenting in a confusing way, jj presents in a straightforward way that makes sense and is easy to remember.

[steveklabnik]

Ah, I use `jj` on WSL every day, so I was confused at first, but that's because I don't share the drive there any more. That absolutely makes sense as a blocker. The autocrlf bit is a bit of a bummer on Windows, too.

> Another relatively minor inconvenience is its inability to use your SSH configs.

This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix".

[sundarurfriend]

I got introduced to jj via Chris Krycho's post on it, but working my way through your tutorial [1] is what made me feel like I understand it enough to actively use in real projects, and also convinced me that jj is the way forward. So, thank you for that!

> The autocrlf bit is a bit of a bummer on Windows, too.

autocrlf is always a bit of mess, to be fair, even when using git. There's never a single good setting because some projects do, for whatever reason, use CRLF for their line endings. (I recently spent 15+ minutes going through my git config and editor config and carefully making sense of things, trying to see why there were spurious line ending changes in my commit, before realizing this project I was contributing to used a mix of LF and CRLF endings in different files!)

[1] https://steveklabnik.github.io/jujutsu-tutorial/

[stouset]

> This should be much better as of last week's release, when you can say "please use git as a subprocess rather than libgit2/gix".

I understand the decision here from an SSH-support situation, but doesn't this feel like a bit of a step backwards?

[steveklabnik]

It’s just a tough spot to be in: libgit2 has always worked a bit differently than the binaries, gix is incomplete. Ideally gix will be good enough that it could just be used, but things aren’t there yet.

[stouset]

Yeah, completely understood. I've suffered from related SSH issues, so I get the motivation. I suppose it's just unfortunate that the supporting libraries aren't quite there yet.

[steveklabnik]

This kind of thing is why jj started with a strong library vs binary split; folks will be able to use the library and have full compatibility with other tools.

[progmetaldev]

Does this mean that NTFS filesystems are affected, even if using from a PowerShell or cmd.exe window, if you are aware? I use git bash or PowerShell daily, but have only used WSL directly for certain processes I am more familiar with in bash than on Windows shells. I've done quite a bit of text processing in WSL, where I just have more experience in the tooling on Linux/bash shell than in Windows, even though I often write dotnet software that runs on Windows, yet uses the open source dotnet and it could run on Linux with a few changes (like making sure I can access MS SQL Server on Azure from Linux, or run MS SQL Server for Linux - I haven't done this, and the CMS I currently use only supports SQLite for development, but require MS SQL Server for production). I might be able to get away with using SQLite for production by only allowing a single user to make edits at a time, and using heavy caching.

I came from a world of Mercurial, and I would love to be able to commit very often, and then be able to squash all those commits into a single commit. I feel git rebase does that, but I haven't been able to truly grok how to do that without running the possibility of completely destroying all changes I've made. I can't lose a giant feature (which is what I generally build) that may take an entire week to build, because I used the wrong git rebase command. I would love to be able to change an individual file and commit it to compare against new changes, but then pull all of these temporary changes/commits and merge/squash them all into a single commit, in case I need to rollback everything due to some breaking update.

[bulatb]

Rewriting a commit in Git (with rebase, --amend, --squash, whatever) creates a new commit with your changes, keeping the original around but detached from the branch. For example, amending the tip of a feature branch (git checkout feature; git commit --amend) turns this:

  A --- B --- C <- [main]
         \
          X --- Y --- Z <- [feature]

into this:

  A --- B --- C <- [main]
         \
          X --- Y --- Z' <- [feature]
                 \
                  Z

The old commit is not destroyed, just taken off the path you walk from "feature" back in time. Even if you `rebase -i main` on "feature" and drop Y and Z, they'll still be around, just not in your branch:

  A --- B --- C <- [main]
         \     \
          \     X' <- [feature]
           \
            X --- Y --- Z

If you're worried about rebase going bad, before you start, create a temporary branch (git checkout -b before-risky-rebase; git checkout -) to mark that line of history where "feature" points at the good state.

  A --- B --- C <- [main]
         \
          X --- Y --- Z <- [feature,before]

If anything goes wrong that `rebase --abort` doesn't fix, get out of there somehow and `git checkout before-risky-rebase`, or, on "feature," `git reset --hard before-risky-rebase`. Here, the backup branch "before" is still what "feature" was before the rebase:

  A --- B --- C <- [main]
         \     \
          \     X' --- (bad) --- (oops) <- [feature]
           \
            X --- Y --- Z <- [before]

As long as you don't force-push anything, it doesn't really matter if you damage the now-broken branch even more while getting out. Reset "feature" to your backup and it never happened. You can even damage "main" and still `reset --hard` to origin/main (if you have one) or the tip "main" had before you broke it.

Even if you don't remember to create the backup branch, the hashes of your old commits now bypassed are still in the reflog. You can always find the hash where "feature" used to point and manually move the pointer back:

  git checkout feature
  git reflog
  (find the hash)
  git reset <hash> # --hard or --mixed if needed

Not that this is obvious or trivial or anything. It shouldn't be this hard. But your commits are safe from almost any way you might destroy them once they're somewhere in your history, at least until unreachable commits are eventually garbage-collected.

[progmetaldev]

I appreciate you taking the time to write all this out for me! This is really helpful in understanding rebasing, and generally how the commits work.

[bulatb]

Great! Happy to help.

Git is like that Brooks quote became software. "Show me Git commands and I'll continue to be mystified; show me history and I won't need your commands."

The official book on their website goes through most of Git like this, if you want to know more. It's really night and day once you know what it's actually doing.

[zipy124]

you can instead use btrfs for your drive so you can access it on windows and linux, as the windows btrfs driver[1] is rather mature these days!

[1]: https://github.com/maharmstone/btrfs

[wodenokoto]

What’s the benefit of running gut from WSL and keeping the files on NTSF? I keep everything in wsl, but now I’m wondering if I should move my git repo to OneDrive

[mkl]

My reason is the combination of a good command line and also easy use of native GUI apps. The main problem is that operations involving lots of little files can be slow (WSL1 is better than WSL2 at this).

[myst]

You problem is Windows, not jj.