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

Jujutsu at Google [video]

youtube.com

Post reply on HN
Print view View original

201–210 of 212 posts

Re: Jujutsu at Google [video]

#201

Post by 1718627440 »

sfink wrote: post #200
1718627440 wrote: post #193

Earlier quoted context omitted.

> But you're kind of fighting against the grain to do it. > `jj absorb` git absorb exists.

It may be unclear since I screwed up the formatting of my post, but that's why I didn't end there. The rest of jj's capabilities change when and how I use it. The absorb command originated in mercurial, which is where I've used it most. With `hg absorb`, I'd only use it when I was fairly sure that it would do the right thing, and I imagine it'd be the same with git. With jj, having `jj undo` as a fallback means I can…

git absorb doesn't rewrite anything, it just creates commits you can use with autosquash, so you see what you would change first.

Re: Jujutsu at Google [video]

#202

Post by verdverm »

aidenn0 wrote: post #141
verdverm wrote: post #128

Earlier quoted context omitted.

The development world is much different and entrenched than it was when the move from svn -> git happened. Think of all the tooling, integrations, and automation we use these days. That was not happening 15+ years ago. I don't think svn as an analogy holds much water, tbh

Tooling, integrations, and automation (Including CI) were all things we used at my work when we switched from CVS to SVN almost 20 years ago.

Some people were, yes, but the scale of this has changed in those 20 years as well

Re: Jujutsu at Google [video]

#203

Post by verdverm »

steveklabnik wrote: post #122
verdverm wrote: post #121

Earlier quoted context omitted.

right, but then I'm using git, not jj, so why jj? Why do people believe it's going to replace git if it won't do basic things we need. Why is it hard for jj to create a tag?

It’s not. It’s that there’s no inherent advantage to doing it natively when it works just fine via git. There’s more important things to do first, like many of the things on your list. It’ll get there! Early days.

The advantage is in not requiring multiple tools to do the job when one already does it fine by itself.

jj claims there are these really bad problems with git, which is not my experience. Git is not on my list of pains in dev work

Re: Jujutsu at Google [video]

#204

Post by stouset »

1718627440 wrote: post #174
martinvonz wrote: post #168

Earlier quoted context omitted.

Yes, it's certainly possible to do all those things with Git. Compared to jj, it's just much harder to do, easier to mess up, and harder to recover from if you do mess up.

I just gave you an example how it is not "much harder".

I don’t know about you, but I am tired of having to remember the dozens of simple, one-off workarounds to every single thing I want to actually accomplish.

A few months back I had to sanitize the commit history of a repo that needed certain files removed from the entire history. I could have read the manpage for `git filter-branch`, but in jj editing commits is just a normal, sane part of your workflow. It was a blindingly obvious one-liner that just used all the commands I use every day already.

Even better, it was fast. Because “edit the contents of a bunch of commits” is a first-class operation in jj, there’s no need to repeatedly check out and re-commit. Everything can be done directly against the backing repository.

Re: Jujutsu at Google [video]

#205

Post by stouset »

caconym_ wrote: post #134
nh23423fefe wrote: post #23

Earlier quoted context omitted.

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

I think people who grasp the basic idea of a commit graph and approach it in terms of "this is how I want to manipulate the graph, what are the tools that will allow me to do this?" find it easy, and people who approach it in terms of building a cookbook of commands that comprise a workflow don't.

I am somebody who deeply cares about my commit graph. I want to maintain clean history, and I want to regularly amend previous commits (until merged) in order to tell a coherent story about development. I want to keep unrelated commits on separate branches, so they can be reviewed and merged independently.

I understand how to do these things, but git’s interaction model makes it tedious at best and hard at worst.

jj’s interaction model makes these things simple, straightforward, and obvious in the overwhelming majority of cases.

Re: Jujutsu at Google [video]

#206

Post by 1718627440 »

stouset wrote: post #204
1718627440 wrote: post #174

Earlier quoted context omitted.

I just gave you an example how it is not "much harder".

I don’t know about you, but I am tired of having to remember the dozens of simple, one-off workarounds to every single thing I want to actually accomplish. A few months back I had to sanitize the commit history of a repo that needed certain files removed from the entire history. I could have read the manpage for `git filter-branch`, but in jj editing commits is just a normal, sane part of your workflow. It was a blin…

I don't remember anything really, I just derive it on demand from first principles and by using autocomplete in the shell.

I don't consider `commit --fixup` to be some arcane workaround, that is basically the default to record a change to some older commit.

Editing commits is also a normal, sane part of my workflow, what else is a version control system supposed to do? I consider modifying every commit in a repo not to be that frequent, but nice if JJ supports that easily. Do you want to educate us of the command?

Git also does certain modifications entirely in memory, but when I edit some file obviously my editor needs to access it. Also I want to rerun the tests on some modified commit anyway, so to me checking it out is not some extra cost.

Re: Jujutsu at Google [video]

#207

Post by 1718627440 »

martinvonz wrote: post #189
steveklabnik wrote: post #182

Earlier quoted context omitted.

Oh yeah I forgot HEAD Is a ref, whoops. Duh! (My git is getting rusty at this point...) jj still ends up keeping information in here that the reflog doesnt, but you're right that these aren't the strongest points.

One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches separately AFAIK.

      --update-refs, --no-update-refs
           Automatically force-update any branches that point to commits that
           are being rebased. Any branches that are checked out in a worktree
           are not updated in this way.

           If the configuration variable rebase.updateRefs is set, then this
           option can be used to override and disable this setting.

Re: Jujutsu at Google [video]

#208

Post by IIsi50MHz »

1718627440 wrote: post #190
Agingcoder wrote: post #111

Earlier quoted context omitted.

I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things. My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home. Now, if you’re able to indicate…

That's why it is called a lecture. :-)

It's not even a lecture if all they do is read from the book. I'd say that's one step away from phoning it in. (-:

Re: Jujutsu at Google [video]

#209

Post by 1718627440 »

IIsi50MHz wrote: post #208
1718627440 wrote: post #190

Earlier quoted context omitted.

That's why it is called a lecture. :-)

It's not even a lecture if all they do is read from the book. I'd say that's one step away from phoning it in. (-:

The act of reading to an audience IS what is called a lecture.

Re: Jujutsu at Google [video]

#210

Post by martinvonz »

1718627440 wrote: post #206
stouset wrote: post #204

Earlier quoted context omitted.

I don’t know about you, but I am tired of having to remember the dozens of simple, one-off workarounds to every single thing I want to actually accomplish. A few months back I had to sanitize the commit history of a repo that needed certain files removed from the entire history. I could have read the manpage for `git filter-branch`, but in jj editing commits is just a normal, sane part of your workflow. It was a blin…

I don't remember anything really, I just derive it on demand from first principles and by using autocomplete in the shell. I don't consider `commit --fixup` to be some arcane workaround, that is basically the default to record a change to some older commit. Editing commits is also a normal, sane part of my workflow, what else is a version control system supposed to do? I consider modifying every commit in a repo not…

> Do you want to educate us of the command?

Not sure that they had in mind but you can do `jj squash --from :: --destination 'root()' `. That will take the changes to the unwanted file from all those commits and move them into a new commit based on the root commit (the root commit is virtual commit that's the ancestor of every other commit).

Post reply on HN