Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

Post reply on HN
Print view View original

261–270 of 283 posts

Re: The creator of Jujutsu has joined ERSC

#261

Post by dullcrisp »

1718627440 wrote: post #257
dullcrisp wrote: post #244

Earlier quoted context omitted.

Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah. But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only lettin…

> Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you…

> I did not like it at all.

Because it left you fewer opportunities to experience the ecstasy of typing git commands into a terminal? Or because it didn't work so well?

Re: The creator of Jujutsu has joined ERSC

#262

Post by saghm »

Waterluvian wrote: post #101
saghm wrote: post #90

Earlier quoted context omitted.

All but one of my employers have used either Github or Gitlab, and at every one of them there were a litany of complaints about whichever one we were using. It's kind of surprising to me that someone might not immediately recognize that there's certainly potential there for something better suited to what companies are actually looking for. Obviously there's no guarantee of success, and maybe the problem is too hard…

I think it’s partly about how many steps back you take. Take another step back and you might see a new option that will in ten years be added to your list of options lots of people use and have plenty of complaints about. I’m not saying not to try or that there’s no value in turning the wheel once more. But I used to be excited about these kinds of things and now I’m not because I’ve seen the cycle a few times now.

Yeah, it's unrealistic to think that everyone will be happy and there will be no complaints, but the median view of most products I've used at workplaces has been close to neutral. The sentiment towards Github and Gitlab seems a lot more negative overall at everywhere I've worked relative to how much people like or don't like them for personal stuff, and at least to me that seems like a sign that there's still potential room for improvement in the enterprise offerings.

Re: The creator of Jujutsu has joined ERSC

#263

Post by saghm »

skydhash wrote: post #243
saghm wrote: post #237

Earlier quoted context omitted.

Can you give me a a terse summary of what "checkout" means that doesn't involve needing to either list or ignore several very different types operations?

I would say “align the worktree (or part of it) to a specific state previously saved in the repository.” The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

That sounds like an incredibly leaky abstraction to me, and pretty much exactly what I meant by the UX not being very good.

Re: The creator of Jujutsu has joined ERSC

#264

Post by saghm »

skydhash wrote: post #193
stouset wrote: post #149

Earlier quoted context omitted.

I honestly kind of think your experience is in favor of the GP’s assessment.

Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.

I don't think this framing makes much sense; playing piano isn't a "tool" that you use to achieve some other task, it's literally the goal itself. Using git is not the goal, it's the tool I use to do something else, and needing to learn the underlying theory of how a tool works that's only a small part of how I do my job is not a good user experience.

Re: The creator of Jujutsu has joined ERSC

#265

Post by saghm »

skydhash wrote: post #213
drob518 wrote: post #201

Earlier quoted context omitted.

Yes, really. You just proved the other poster’s point. He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset. Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git comma…

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version con…

> I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

I'm not sure I understand how "I use a specific text editor with a specialized interface into git that's superior" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a CLI. Either way, we've opted out of the actual experience of the tool in favor of using an alternative tool that operates on the version control.

Re: The creator of Jujutsu has joined ERSC

#266

Post by skydhash »

saghm wrote: post #263
skydhash wrote: post #243

Earlier quoted context omitted.

I would say “align the worktree (or part of it) to a specific state previously saved in the repository.” The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

That sounds like an incredibly leaky abstraction to me, and pretty much exactly what I meant by the UX not being very good.

What is version control to you? For me it’s basically being able to store and retrieve snapshots of code at different instances of time, where each instance has its own significance. Checkout have a very precise meaning in that regards, just like add and commit.

Maybe you can explain how is it leaky based on your understanding of version control?

Re: The creator of Jujutsu has joined ERSC

#267

Post by skydhash »

saghm wrote: post #264
skydhash wrote: post #193

Earlier quoted context omitted.

Not really. Learning the piano and learning music theory is two different things but tied together. One is skill and muscle memory, the other is theory and understanding. It’s the same with git and version control. One is a process and the other is a tool.

I don't think this framing makes much sense; playing piano isn't a "tool" that you use to achieve some other task, it's literally the goal itself. Using git is not the goal, it's the tool I use to do something else, and needing to learn the underlying theory of how a tool works that's only a small part of how I do my job is not a good user experience.

The goal is to produce music, and such music is generally constrained by music theory. Using git is to version control some software, and version control is dependent on the programmer/team workflow.

At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes.

So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.

Re: The creator of Jujutsu has joined ERSC

#268

Post by 1718627440 »

dullcrisp wrote: post #261
1718627440 wrote: post #257

Earlier quoted context omitted.

> Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you…

> I did not like it at all. Because it left you fewer opportunities to experience the ecstasy of typing git commands into a terminal? Or because it didn't work so well?

Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later.

I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.

Re: The creator of Jujutsu has joined ERSC

#269

Post by skydhash »

saghm wrote: post #265
skydhash wrote: post #213

Earlier quoted context omitted.

> He says “a lot of developers have not learned git IN DEPTH” and you respond by saying that’s not true because you’ve gotten away with just using a small subset You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version con…

> I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt. I'm not sure I understand how "I use a specific text editor with a specialized interface into git that's superior" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a…

Magit doesn’t anything that is not readily available in git. Most of magit usefulness comes from “active objects” (meaning you can act directly on the report of some commands like git-log) and quick command construction due to transient and autocompletion.

It requires the same mental model as git.

Re: The creator of Jujutsu has joined ERSC

#270

Post by Zambyte »

1718627440 wrote: post #227
dullcrisp wrote: post #198

Earlier quoted context omitted.

It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.

> I don’t like to think about how I’d do that with git. git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~ Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.

jj just makes lots of git operations go from "technically possible if you're creative enough" to "<= 3 solutions, one of them probably being obvious". jj lowers the skill ceiling of git, and raises the floor.
Post reply on HN