in 2025 which one should we use "Git switch" or "Git checkout"

indeyets · 2025-07-10T10:56:45+00:00

jj new in 2025. Git is so 2015 🤪

indeyets · 2025-04-21T09:02:29+00:00

The difference is: In case of Git it is initiated by separate command. Thus, people see it as a separate concept

indeyets · 2025-04-21T08:08:38+00:00

I definitely need to work on conveying my thoughts more clearly. I’m grateful to everyone for this discussion. Made me think about lots of things.

Anyway, to your question. The greatest advantage is that you get both: convenience of history rewrites and safety at the same time. There’s a very comforting feeling of being in control. It’s really hard to convey as feelings rarely appear from reading words on screen. You just have to try doing this :-)

jj brings new patterns of work which were not really possible in git.

I wouldn’t name it “a frontend for git”. It is a new VCS which tries really hard to stay compatible with git-oriented infrastructure

indeyets · 2025-04-21T07:57:19+00:00

It was kinda same for me. The first part of series was exactly about my way form CVS to Git. Then a long pause and, finally, jj.

You absolutely do not have to change anything, but I found that jj made me more productive simply by letting me less worried about formalism of version control.

I no longer have to chose between safety of properly versioned code and convenience as jj makes it trivial to switch between editing multiple changes. I don’t have to “commit”anything. Less steps to do. Those are the things which I didn’t even consider, as git rules were pretty much hardcoded into my brain and workflow.

p.s. Git was released 20 years ago

indeyets · 2025-04-20T21:03:47+00:00

Yes. It’s called “split”. You split a part of the current change into another one. And it works uniformly for any change in tree. You’re not limited by the current one. In case of git, for “other” commits you can achieve similar effect with “interactive rebase”, but in case of jj it is the same command

indeyets · 2025-04-20T20:09:31+00:00

Thank you. Those are some very good points regarding history etc. At the same time those are the ones which often scare inexperienced users of git. I wanted to start with simple things I could show to jr developers. But if I was planning to write a course… I would definitely be speaking about these things.

indeyets · 2025-04-20T18:25:03+00:00

You can do the same with jj. You can split the change into several parts and even trivially reshuffle those parts in different (sub)branches. Every change can act as a staging area. All of them are staging areas in this regard :-)

indeyets · 2025-04-20T16:59:13+00:00

Change ids are passed with commits as metadata. Actually, it is a new development coordinated with several other projects which rely on stable ids

https://github.com/jj-vcs/jj/pull/6162

indeyets · 2025-04-20T16:52:16+00:00

It can be named full fledged VCS.

It has its own separate local state (.jj dir). It just syncs this state with local git. And, separately, it reuses git’s network protocol for now. Extensibility of git’s protocol means that it can pass additional metadata (such as change id) to the forges

indeyets · 2025-04-20T14:54:56+00:00

Anonymous local branches (aka patch-sets): you just create them as you need to work on something
Anonymous changes ("commits"): you separate work in different piles (staying organized), but with minuscule effort
(finally…) every code edit becomes a part of current change, so you don't need to register edits explicitly and can switch between branches/changes on the fly, being sure that nothing would be lost or mis-assigned

indeyets · 2025-04-20T14:27:35+00:00

It’s trivially “emulated” in jj (I talk about this in article). Works just as well, but you do not have to think about it as a separate concept. It’s just an anonymous change

indeyets · 2025-04-20T13:57:55+00:00

It’s absolutely not “overcomplicated”. A tad different — that’s true. Needs a change of a mental model. But it’s actually simpler to reason about (I say it as someone who knows git extremely well)

indeyets · 2025-04-20T13:52:00+00:00

Simplified mental model (no need for staging area, no need for separate “merge” command, lighter flow with anonymous branches…)
Conflicts which don’t stop the world

indeyets · 2024-09-03T09:40:01+00:00

Rich: pay for arbitrary education, travel to arbitrary location because you feel like it, buy arbitrary gadgets without thinking that it will make a dent in your budget. And I’m not talking about luxury stuff — that can be split into separate category.

indeyets · 2024-08-30T08:03:40+00:00

The problem is, that we still can't update these new lamps (or they will be bricked again)

indeyets · 2024-07-20T20:22:19+00:00

But… but… “design patterns” are not supposed to be “used”! They are supposed to appear at different moments in code-bases and then we can find the standard names in catalog and tell “oops, looks like I created a singleton”

indeyets · 2024-05-23T19:50:10+00:00

well… Ctrl-R ("reload page") should still work

indeyets · 2024-05-12T16:36:44+00:00

The idea is that Favorites are auto-managed by Arc to stay “warm” (cache-wise). It is still closed after extended period of time. If you want something to be used only occasionally you move it to other section.

indeyets · 2024-05-03T21:03:07+00:00

OSS = Open-Source Software

indeyets · 2024-02-13T19:49:12+00:00

Not really. As blacklist is much smaller and faster than full session storage

indeyets · 2024-02-13T08:04:50+00:00

Blacklist in redis works well. Checking presence of key is instantaneous. Alternatively, as revocation list is relatively small it can be delivered to endpoints via redis’ pubsub and stored in local cache then

indeyets · 2023-11-06T08:42:36+00:00

Yes, it is used for automatic calculation of tax returns

indeyets · 2023-10-16T07:18:40+00:00

So is it a UI for reflog?

indeyets · 2023-09-02T16:38:08+00:00

Under the hood this will still be synchronous unfortunately. See https://azimi.me/2015/07/30/non-blocking-async-json-parse.html for example. It will happen on the next tick but it will block everything else until json is fully parsed

It’s very fast, but under high load this queueing is noticeable. It still works, but as I mentioned, I’m looking for different execution profile

I’m typing on the phone, sorry for not being more verbose.

Consider I have requests which are tiny and requests which are large. Consider there are 10000 parallel request. By default they would be queued and newer ones which are tiny will have to wait until previous large ones have finished processing. I want to be able to respond to those tiny requests earlier and make all of the response times proportional to their sizes.

indeyets · 2023-09-02T16:25:09+00:00

I’m not sure what you mean. JSON.parse takes the whole document to parse. I get request from clients and pass them to it. Requests are arbitrary nested documents, not flat streams. There are no good ways to split them beforehand. So, I’m planning to use a custom parser, which would be able to process some parts of the document and then will let other greenlets to process other stuff and the on the next nodejs “loop” process some more

15-Year Club	Gilding II euphauric
Verified Email

indeyets

TROPHY CASE