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

Jujutsu VCS: Introduction and patterns

kubamartin.com

Post reply on HN
Print view View original

101–110 of 128 posts

Re: Jujutsu VCS: Introduction and patterns

#101

Post by urschrei »

hinkley wrote: post #97
stouset wrote: post #87

Earlier quoted context omitted.

With all due respect, it sounds like you might have some confusion about what happened. If you run `jj new`, `jj st` will virtually by definition show a clean working copy. You've created a new, empty revision, and as a consequence there are zero changes which have been made in that empty revision. Asserting that `jj` "lies to people" is… probably uncalled for here. I'm not going to say it's impossible for the two co…

If I have a working directory with active changes in it, that are not in the ignore file, I expect my VCs tool to show edits in its status. Full stop.

You are confused or wrong, and you are making incorrect assertions about a system "lying" to you on that basis: you can see this for yourself by typing `jj git init` (or just `jj init`) in an empty directory, touching some files, then running `jj status`. You will see a listing of the added files. The same happens if you commit these files, then make some changes to their contents: `jj status` will show the changed files, and `jj diff` will show the diff per file.

Re: Jujutsu VCS: Introduction and patterns

#102

Post by necauqua »

hinkley wrote: post #97
stouset wrote: post #87

Earlier quoted context omitted.

With all due respect, it sounds like you might have some confusion about what happened. If you run `jj new`, `jj st` will virtually by definition show a clean working copy. You've created a new, empty revision, and as a consequence there are zero changes which have been made in that empty revision. Asserting that `jj` "lies to people" is… probably uncalled for here. I'm not going to say it's impossible for the two co…

If I have a working directory with active changes in it, that are not in the ignore file, I expect my VCs tool to show edits in its status. Full stop.

In git terms (this is an analogy that is a bit wrong, but useful here), doing `jj new` after making some changes is the same as doing `git commit -am ""` then.

Would you expect `git status` to "show you the changes, full stop" then?.

Where the hostility is coming from, ugh

Why is it so hard for people to even consider for a minute that they might be wrong or confused - nooo, this tool that was in development for years by at least one full-time google employee with a decade of mercurial dev experience and a ton of contributors, and that is loved by a lot of people already for it's simplicity and functionality - definitely failed in such a basic task, it's not you misunderstanding some basics in how it works, definitely, "full stop".

Another thing is that you might have set a `snapshot.auto-track="none()"` config and never told us, which is an opt-in way to disable autotracking, and which `jj st` does not support fully (if at all in released version) yet - then you totally "opted in" being lied to, sorry.

Re: Jujutsu VCS: Introduction and patterns

#103

Post by [deleted] »

dragonwriter wrote: post #68
pkulak wrote: post #67

>> Changes in jj can be marked with bookmarks (what jj calls branches), JJ actually calls its bookmarks "bookmarks". Maybe these two words got accidentally flipped?

No, the English structure " ... what jj calls " just has an annoying semantic ambiguity, and can either mean " is the name used by jj for the thing that is more commonly referred to as " or "the thing more generally called is referred to as by jj", which is expected to be resolved by the reader on the basis of whether or is the generic term they are familiar with.

[deleted]

Re: Jujutsu VCS: Introduction and patterns

#104

Post by cube2222 »

tripple6 wrote: post #100
mamcx wrote: post #14

Earlier quoted context omitted.

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed. > You can UNDO. Everything. That is the major thing Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index fo…

Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git.

> but does it work as a front-end tool over git/other VCS?

citing from the article

> Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend.

> I don't get it. What does make rebase hard?

It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1].

Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2].

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

[1]: https://graphite.dev/

[2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

Re: Jujutsu VCS: Introduction and patterns

#105

Post by steveklabnik »

ashenke wrote: post #80
gcr wrote: post #78

Earlier quoted context omitted.

As long as you don't use `--allow-backward` or `--ignore-immutable`, and as long as everyone sticks to their own feature branches, this shouldn't be possible. The operation log makes jj quite safe. There's a command to restore the entire working copy + history to an earlier state in case you screw something up. Even this operation log is itself versioned, so you can undo the undo if you screwed the undo up, ad infini…

For every feature we usually have two developers working on it, one frontend and one backend, working on the same feature branch. Would Jujitsu cause a problem in this context?

Just to be clear, as with git, you don’t have to rebase. It’s just that doing so is nicer in jj. But if rewriting commits on a shared branch becomes onerous, don’t do that!

Re: Jujutsu VCS: Introduction and patterns

#106

Post by steveklabnik »

zellyn wrote: post #99
BeetleB wrote: post #82

Earlier quoted context omitted.

You can name them if you want.

Hah. I didn't even realize you could _not_ name them. I just do: jj b c zellyn/appname-update-plugh-tests jj git push

jj git push -c will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.

Re: Jujutsu VCS: Introduction and patterns

#107

Post by steveklabnik »

renox wrote: post #96
dartos wrote: post #8

Earlier quoted context omitted.

I switched from git to jj a few months ago, so I may have some insight. I used it at work, where everyone used git, and there were 0 issues. What I really like about it is how changes are sort of soft committed right away and, when I checkout a different branch or change, I don’t need to stash my changes and remember the stack of stashes. Rebasing and merging feel a little easier, but that might just be because “ours…

> The only tangible downside for me is that it doesn’t support git hooks Thanks for this information: at work we use them for creating gerrit review id, so I'll wait until jj get this feature.

There’s workarounds for that, including an open PR for a dedicated integration.

Re: Jujutsu VCS: Introduction and patterns

#108

Post by steveklabnik »

sfink wrote: post #81
steveklabnik wrote: post #61

Earlier quoted context omitted.

The nickname for these two is the "edit workflow" vs the "squash workflow," and both are good to know, for sure!

Sorry, I knew I remembered reading about the two somewhere but could not figure out where. I searched through the jj page for it. Only later did I remember that it came from your jj guide, which I still had open in a tab. I wish I had pointed to your explanation, it's much more clear. Better late than never: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

It’s all good! More people writing stuff out is a good thing. You never know which phrasing resonates with more people.

And to be clear I didn’t coin these nicknames, I got them from the community.

Re: Jujutsu VCS: Introduction and patterns

#109

Post by martinvonz »

tripple6 wrote: post #100
mamcx wrote: post #14

Earlier quoted context omitted.

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60…

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed. > You can UNDO. Everything. That is the major thing Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index fo…

I think the best way to answer most of your questions is just for you to try it yourself (https://jj-vcs.github.io/jj/latest/install-and-setup/).

> Everything is what?

Not interactions affecting remotes (you can't unpush a commit). Configuration is also not tracked. Neither are ignored files.

You can undo changes in the working copy, rebases, splits, squashes, etc.

> The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset.

Files added to the index can be recovered at least, but it's not easy to find them. The bigger problem is if you have not added them to the index and run e.g. `git reset --hard`. You can't undo that (via Git, but maybe via your IDE or your file system).

It's also about ease of use. I know you can undo a lot of things by using Git's reflogs, but it's not easy to e.g. undo a `git rebase --update-refs` that update many branches.

> I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage.

Yes, Jujutsu also supports that (`jj workspace`), but IMO, it's nice to not have to use them just because your working copy is dirty.

> What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode.

I've worked on the `git rebase` itself, so it's not like I don't know how to use it. Some things that I think are wrong with it:

* Without `--update-refs`, it only rebases a single branch. That's basically never what I want when I have branches pointing to other rebased commits.

* It's not able to rebase more than one head (no trees of commits)

* Doesn't rebase merge commits properly. Instead, it redoes the merge, discarding any conflict resolutions. (Yes, I know about rerere.)

> Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

Mostly that it's so stateful. While doing an interactive rebase (e.g. editing a commit), you're in a state where you can't easily check out another commit, for example. If you run into conflicts, you have to finish resolving all conflicts in the stack of commits, or you have to abort the whole rebase (throwing away any previous conflict resolutions).

Again, it will be easier to understand if you just try using Jujutsu for a few days.

Re: Jujutsu VCS: Introduction and patterns

#110

Post by tripple6 »

cube2222 wrote: post #104
tripple6 wrote: post #100

Earlier quoted context omitted.

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed. > You can UNDO. Everything. That is the major thing Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index fo…

Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git. > but does it work as a front-end tool over git/other VCS? citing from the article > Before we dive in, one last thing you should take note of, is that most people use jj wit…

Regarding the rebase thing, I guess it's more a matter of habit. Stacked branches indeed may be tedious and may be annoying to rebase, agree. I implemented a shell script to rebase branch trees on top of a new base that would cover stacked branches as well. It covered all my needs like resolving conflicts, concluding or aborting the branch tree rebase and so on. Of course, it would be nice to have such a right-done thing right in git. But as of now, if I understand what jj is, it seems like I can shell-script some of its features myself. Still a happy git user.
Post reply on HN