HaraldvonBlauzahn @ HaraldvonBlauzahn @feddit.org

Posts

30

Comments

139

Joined

3 mo. ago

I agree with you. Better responsivity, better UI, better privacy, keep your data collected in one place which is your computer's hard drive.

Now, jujutsu covers almost the same with < 10% of that complexity and less than 10% of the documentation - simpler but the same power.

And from what I can tell it's much easier to do a git pull upstream master than to do jj new skdfsld dskfjas since you'll likely have to lookup those hashes? I mean I wouldn't remember them.

One takes them from the last commit log and uses the first few letters. Steve Klabnik shows how they are used in practice. It makes no sense to repeat it here.

So you think that git has already a perfect user interface?

Well, the thing that this seeks to improve on is the crazy complexity of advanced git commands, which gave rise to several humorous mentions on XKCD and even satire man pages like this:

https://git-man-page-generator.lokaltog.net/

..... and if you think that you know most of git well, then, quick, what happens when you merge two branches of a repo which has several changed submodules in each branch? Is this deterministically resolved, and if so, how?

Yeah you can undo undo and also resurrect undone states.

If the readability of the commit history really does not matter to you - for exsmple, nobody needs to read this code again - it's possible that jj does not give you enough advantage. Everyone works different.

I have to admit that in spite of having used git for about 20 years, I never used reflog. And even with magit I did stuff like rebase rarely. I found it costing too much time to read the man pages again every time and meditate what would happen with "reset xyz".

jj by default refuses to change any commits on published branches such as a master branch that has been pushed. The details are configurable.

BTW that's why I linked Linus Torvalds mail on when and why to rewrite history - it is good advice.

And since they eschew branches with names you get to memorize hash strings instead of branch names that describe the thing you were doing?

No trouble, you can still name branches if you want. And no, you don't have to type the whole changeset hash, the first one to three letters are usually sufficient.

Also, branch names are not a permanent thing, they disappear after you merged them.

If you want, to can put an empty commit with the description of what you want to do at the top of your changes, and then use "jj split" to move changes to different commits before it. There are several common work flows which are explained in Klabnik's blog post.

There are video overviews on jujutsu but I admit that I am not motivated to look it up for you.

One difference between using worktrees and branches in git is that in git you usually have uncommited stuff that's not finished, and worktrees are a way to avoid committing this. And you want to avoid committing early because it is hard to clean-up later. This hesistsnce to commit is not necessary at all in jujutsu - any change to the source files is already captured and will be restored once you go back to that changeset. There are other cases where you use worktrees in git e.g. to isolate a build and an hour-long integration test running it in parallel to your ongoing work, and in thar cases, you'd use workspaces in jujutsu like you'd in git.

but then we would need to talk about what about the git model people have trouble with, why

Too many commands that do subtly and irreversivly things on the repo, with potentially messed-up interim states, only to do the conceptually much simpler task to edit and manipulate the directed acyclic graph of commits.

In short, jujutsu is a commit graph editor and does the same with perhaps 10% of the complexity of git. The man pages on the git reset, branch and merge commands are already larger than the whole - and detailed!- documentation of jujutsu.

Steve Klabnik explains this much better than I can here in his blog that I posted.

Now the interesting question is what it really means when less experienced programmers think they are 100% faster.

Another useful property is that while jujutsu does have worktrees, like git, in many cases where one would use git worktrees (for example when writing accompanying documentation ) it is just easier to use another line of changes (what is a branch in git).

Alas, that jujutsu does not store local change sets automatically on a remote git repo (this happens only when you update and push a git branch), means that still-mutable local changes are not automatically transferred to another computer you work on. And unpublished changes are naturally mutable in jujutsu. But you can safely copy a jj repo via rsync, as changes in jj metadata are thread-safe and atomic. The other way is of course to push a work-in-progress ("WIP") git branch which can muate and is therefore not allowed to be merged by other people.

I would be curious to know in which specific cases people which have experience with using both think plain git is still better.

In my experience, when using jujutsu it can be necessary to use git commands to access repos via ssh, vpn and such. Also, jujutsu ignores git submodules, so one has to do submodule operations with git (but I think that culturally, using submodules most often is not such a good idea).

Magnesium frame and such. I had an older and heavier one and was always joking it would come handy as a blunt weapon if there was a sudden monster attack. It once fell from my desk to the floor and didn't even had a scratch.

Plus if you are on budget it is really best value for the money.

Check ThinkWiki and Thinkpad wiki sites for details. You do not need high specs to run Linux.

Just a general recommendation for that kind of question:

1. Note down the requirements you have
2. Go to the software list in the Arch wiki, http://wiki.archlinux.org/
3. Check out the list for that application area and see and try which program matches your requirements.

(Guix package manager can be helpful if your distro does not have this native package; it can without any problem run on top of your distro.)

Having used the wiki, you can even claim you are an Arch user! ;-)

Depends what I am doing, but I often like "orthodox" two-pane file managers better, with details.

So my preference list is roughly:

1. Command Line
2. Krusader
3. Thunar

Looks like not officially published yet with a date and journal, aka a pre-print.

So, but what is the current state of this issue? Any plans to move it to a GNUnited Nations server?

Sometimes, a solution which reliably covers 90% of use cases in a very simple way is the best solution for 90% of users.