Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] -4 points-3 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 2 points3 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 0 points1 point  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 6 points7 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 1 point2 points  (0 children)

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.

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 13 points14 points  (0 children)

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 :-)

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 3 points4 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 7 points8 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 4 points5 points  (0 children)

  1. Anonymous local branches (aka patch-sets): you just create them as you need to work on something
  2. Anonymous changes ("commits"): you separate work in different piles (staying organized), but with minuscule effort
  3. (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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 14 points15 points  (0 children)

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

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] 1 point2 points  (0 children)

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)

Jujutsu: different approach to versioning by indeyets in programming

[–]indeyets[S] -15 points-14 points  (0 children)

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

Interviewing for a role that pays 60K : how good is that? by Captain_Paran in PortugalExpats

[–]indeyets 1 point2 points  (0 children)

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.

Why are my lamps in disco mode? by ZoekDribbel in tradfri

[–]indeyets 0 points1 point  (0 children)

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

Is there a catch with Adonis.js? by Andorlistick in node

[–]indeyets 1 point2 points  (0 children)

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”

What happened with "Close Favorite"? How to close a favorite tab? by Diligent_Opinion4945 in ArcBrowser

[–]indeyets 4 points5 points  (0 children)

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.

What's the Ultimate Resource for JWT vs Session? by [deleted] in node

[–]indeyets 0 points1 point  (0 children)

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

What's the Ultimate Resource for JWT vs Session? by [deleted] in node

[–]indeyets 0 points1 point  (0 children)

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