Things have changed since, but in my time, if a journal required source code for publication, most of the professors in my department would not have published there.

The professor can always set his terms, and it's up to a student to have him as an advisor. In both universities I attended, there were professors who were very fussy about how much research they did and how much money they brought in (could be 0), and if a student wanted them as an advisor, they needed to understand the risks involved.

So he switched universities.

But still, didn't he worry that he'd bump into his former professor at a conference and that he would tell his new advisor? I don't know if he made some deal with him ...

Pre-LLMs, what motivated you? Why did you do what you did?

This article really doesn't address the original essay's point: Why is the universe so logical/mathematical? Yes, a lot of math exists to model the real world. But why does reality follow rules that are easy to model?

At the same time, knowing someone who committed academic fraud during his PhD and was caught, I can say two things:

A lot of people do it when they simply don't need to. They're not trying to "survive in academia". They're trying to get to the top. The person in question was smart, bright, and did good research (at least excluding the stuff he made up). He could have gotten an academic position without committing fraud. And he could have had a great industry job without it too.

No matter - he simply switched to another top tier university, got his PhD, and is now running a startup. Which comes to the second point: The repercussions are minor even when you do get caught.

With jj, it's the same as any other commit. No new commands, no new options.

The problem with the article is the complete lack of details. No benchmarks on the iPhone capable models. No details, whatsoever.

Human or LLM - the article is a whole lot of nothing.

Using a version control tool shouldn't require much self discipline.

With branches, jj is to git what git was to SVN. It's an order of magnitude less friction to do branching in jj than git.

Not long ago, I pulled from main and rebased my branch onto it - merge conflicts. But I wanted to work on some other feature at the moment. Why should I have to fix this merge conflict to work on a feature on a totally different branch? With jj, I don't. I just switch to the other branch (that has no conflict), and code my new feature. Whenever I need to work on the conflicted branch, I'll go there and fix the conflict.

Once I started using jj, I realized how silly it was for git to have separate concepts for stash and index. And it's annoying that stash/index is not version controlled in git. Or is it? I have no idea.

In jj, a stash is simply yet another unnamed branch. Do whatever you want there. Add more commits. Then apply it to any branch(es) that you would like to. Or not.

Why does git need a separate concept of a stash? And wouldn't you like a version controlled stash in git?

Have you ever made a ton of changes, done a "git add", accidentally deleted some of the changes in one file, done a "git add", and thought "Oh crap!" I suppose that information can be recovered from the reflog. But wouldn't you wish "git add" was version controlled in the same way everything else is?

That's the appeal of jj. You get a better stash. You get a better index. And all with fewer concepts. You just need to understand what a branch (or graph) is, and you get all of it. Why give it a name like "stash" or "index"?

Why does git insist on giving branches names? Once you get used to unnamed branches, the git way just doesn't make sense. In jj you'll still give names wherever you need to.

I've used jj for only a year, and have used "jj undo" countless times.

There's a huge benefit to having a simpler mental model.

Another option is to make a branch with the files that you want to keep around but not push (e.g. stuff specific to your own tooling/editor/IDE), and mark that branch as private. Private commits (and their descendants) can't be pushed.

You then make a merge commit with this branch and main, make your changes, etc. You will have to rebase before pushing so that your branch isn't a descendant of the private commit.

This will involve more work, but it has the benefit that you're actually version controlling your other files.

The jujutsu docs have a page for this - it has everything I needed.

https://docs.jj-vcs.dev/latest/github/

Classic denying the antecedent :-)

https://en.wikipedia.org/wiki/Denying_the_antecedent

For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit.

Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to.

Oh, and not having to deal with merge conflicts now is awesome. My repository still has merge conflicts from months ago. I'll probably go and delete those branches as I have no intention to resolve them.