Yup, there are attscks. Also ddos on Codeberg and the xz-utils backdoor.

I’d say look after your kid and try out Linux a bit later when you have Leisure for it. You can use Linux and Windows in parallel on two computers networked with Samba.

For Rust, return Result<> , as is idomatic in Rust.

Another possible method is having an installable handler that handles the error at the place it is detected. Common Lisp does that and it is very powerful.

Commit separation that is useful for review will also be useful for history.

Also when using git bisect aka “The Alaskan Wolf Fence Method” on nasty bugs e.g. causing concurrency or UB issues.

It is also a potential downside of rebasing that it can (sometimes) invalidate interim tests.

You could try also:

• GNOME PaperWM, a GNOME extension with tiling and endless horizontal scrolling
• niri
• StumpWM, a tiling WM with Emacs-like keybindings (and zero eyecandy and waste of screen estate)
• HerbstluftWM

Have you ever seen or created something like this?

This might explain why it might be useful to re-write history at all, and why tools like jujutsu or gerrit are interesting, in specific contexts.

BTW there are two configurations / new commands that could be helpful for you:

• there is a configuration option (auto-track='none()', already mentioned by other commenterd here) to switch off auto-adding of new files
• there is an alias command, tug that automatically advances branches / bookmarks to the current commit / change.

Oh, I was referring to people who do not want to believe at all there could be something easier to use than git. Probably not the best way to express this.

I don’t know whether it fits your use case. You decide that.

Also, jujutsu is still immature and has many rough edges.

Yeah you could view jujutsu as git with a simpler and more tidy CLI.

Telling people they have Stockholm syndrome is not a good way to convince them to change their behavior.

Yeah that’s probably not the best way to express it. Perhaps it is more like:

Git is huge and complex to learn, and some people have spent a lot of time to learn it - hundreds of hours.

Now, eyeing jujutsu, they expect that for doing this complex task with jujutsu they will again have to learn a very complex interface, with a lot of effort, and they decide it probably ain’t worth it. Which by the way, for software is a reasonable heuristic most of the time.

So if somebody tells them that jujutsu is less effort to learn to do complex tasks, they don’t believe it and that’s it.

It also seems to happen frequently that people try jujutsu, but it does not click for them, they try commands but they do not get what’s the advantage - perhaps because it is too different from git. And later they try again and it clicks. Steve Klabnik described that for himself.

Moreover some people don’t need to do complex tasks.

And people in general hate it when interfaces change in unwanted ways. Which is human nature too and a valid way to allocate time and attention, which both are a scarce resource.

For me, I am and have been using it in two different situations:

• at work, when I was writing tests and documentation for an old numeric library somebody else wrote, and tests for an OS abstraction layer for real-time systems. With git, I used to use worktrees to keep and extend the documentation in another branch. I found that in jujutsu, a worktree was not needed because it was easier/quicker to work on different branches (or series of changes) than in git.

• at home, in two leisure projects written in Guile and Rust. Here, I wanted a clean/tidy history including for the parts that were developed in an experimental manner. With the git CLI, that would have required heavy use of rebase and so on. I would have used the Magit git interface, but most likely I would have avoided most of the tidying up because of the extra effort1. With jujutsu, this was much less effort - it was fun.

Currently, I don’t use jujutsu at work because I am taking over an old legacy project from an almost-retired developer and he is still helping me explaining things and looking at his last changes in the maintenance branch. I don’t want to burden him with a new tool as his time is very scarce. (But jujutsu is perfect for things like “throwaway refactoring” of legacy code, so I will for sure use it in the future).

BTW, I was using git CLI since 2008 or so, and Emacs/Magit since about 2017, full time. But I often needed to look up more complex git functions in the man pages.

squash exists but it squashes commits.

The rebase command is a bit more flexible but a key difference is handling of conflicts: They represent as regions with conflict markers in the conflicted text regions and all following commits/changes, and they disappear once the conflict has been resolved. No weird interim stated and git rebase --abort. If you want the old state back, you only need to do jj undo and that’s it.

I create lots of log files and other temp files when I work. Maybe I just fetched some .json from a service and put it in tmp.json? Maybe I created a small shell script to automate something I’m doing?

You might be able to put them into .gitignore. But why not keep the shell script in a tools folder?

I can see that - but that’s a “less frequent” task than me switching between branches.

My observation is that one happens to edit the commit graph much more often because it is so effortless.

And the analogous thing to switching a branch is:

jj

to get the log. And then, with say “qx” being the abbreviated commit id I want to append the next change to:

jj new qx

and now I am already working at the right series of changes.

Because I like a lot to focus on one single thing, the next thing I do is often

 jj desc

which opens $EDITOR with the commit description and lets me write down what I am going to add or change.

That commit description also shows up in the log command, so I know always what the change is about.

jujutsu changes a lot of the affordances to manage changes and I understand that many people will be reluctant to use such a changed interface - for one, after they have spent so much time with learning the git CLI, and also because there are dozens of alternative git UIs and VCSes which claim to offer something simpler.

But: jujutsu offers about similar power and flexibility as git, while requiring much less UI complexity. The proof for this is the much, much smaller amount of required documentation as well as practice before one can work productively with it.

All the changed elements give a very orthogonal and cohesive whole, which is very rare for software of that complexity.

Will this work for everyone? Probably not, that happens extremely rarely.

Will many people pick it up on a whim? No, change does not happen that way. In the ideal case, a kind of logistic function but adoption will be very unlikely to be as rapid as git’s adoption.

Will experienced git users drop the work they have to do and spend half a day to try a new tool? Some do, and this is good. Some don’t, and this is also good.

So, no, I don’t have a problem. People have time and decide to look at something or they don’t. Both is fine.

More shortcomings of jujutsu:

Some things that are also missing are signing commits and such, but again one can use git for this.

Also, git servers and tools like github, gerrit etc. don’t know about jujutsu’s change ids, so the advantages are kept local. But this is changing, the tools are adding this metadata.

Also, one can sync up jj repos with rsync, which transmits the change ids.

gitk shows many temporary commits which is distracting.

It obsoletes Emacs Magit, which means vim is the better choice for editing commit messages, which means you see yourself morphing into a vim user. Or maybe emacsclient.

Building jujutsu from source requires a fairly up-to-date Rust environment. (One can download a binary that is statically linked with musl from github but I hate downloading binaries). Debian stable has not even an out-dated version. Building it under Guix’s cargo took me some tries.

If you work on a Mainframe or Tandem system, you’ll need to wait until your system’s Rust port is done. A hefty requirement compared to the needs of building git.

Seeing the list of dependencies makes one wonder whether it was written in node/js.

agate and amfora, a server and client for the text-based “small web” protocol called Gemini. Allows to publish and read text, images and media in a really simple and accessible way.

(Works also great in a local file network to distribute media and docs).

simple-scan. Scans documents with zero fuss. Easy and intuitive which is important for software that is not used frequently.

The Zim Desktop Wiki. Backed by files stored in git, lightweight and fast, ideal to capture and organize unstructured information.

Also, ledger.