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

Jujutsu: A Git-compatible DVCS that is both simple and powerful

github.com

Post reply on HN
Print view View original

241–250 of 269 posts

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#241

Post by h0l0cube »

arxanas wrote: post #142
h0l0cube wrote: post #65

Earlier quoted context omitted.

I'd be curious to know if someone is successfully using this in a team. How is it when two people are working in the same branch?

It's not really different than using Git to work on the same branch. If you and the teammate commit to the same branch, then you'll need to resolve the divergence somehow, usually a merge or rebase, or choose to forcibly overwrite the other's changes.

I can theorize about how it might work in a team also, but I was curious how this has played out in practice for anyone

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#242

Post by Double_a_92 »

kuchenbecker wrote: post #231
Double_a_92 wrote: post #128

I never understand such projects... How is git hard, especially compared to the complexity of most things that you would even commit to your git repository?

Working on large complex projects the main branch will have dozens or hundreds of commits per day pushed continuously. The value is a consistent and linear commit history moving from known-state to known state. Facebook version control system built on mercurial is the best I've used. One of the huge benefits of the rebase based workflow is commits can be reordered and land as they pass tests rather than a single line…

You all work on one shared main branch, without any feature branches? Isn't it horrible to have other people half-finished code in the code that you are trying to work with?

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#243

Post by eviks »

arxanas wrote: post #236
eviks wrote: post #226

Is there any good GUI client supporting this?

One of our Discord members had a prototype implementing support in IntelliJ if you want to try that. Other than that, I'm not aware of any jj GUI clients. However, you can use jj directly in Git repositories with the colocated mode and then continue using your preferred Git GUI client. (Obviously, you miss out on the jj-only features.)

Thanks, maybe will try the co-located mode since I only use cli git for some operations not covered by GUI, and git cli UI is atrocious

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#244

Post by sicariusnoctis »

ocharles wrote: post #168
rkangel wrote: post #155

Earlier quoted context omitted.

I almost always do "git add -p", "git commit". "add -p" is great for showing you all the chunks of code you've written one-by-one and then you do "y" or "n" for whether you're adding them. Doing it like this means that you are reviewing what you've changed as a final check that you haven't left a debug line in, or forgotten part of what you meant to do. It's also a natural way of splitting up what you've done into tw…

The analogous command here is `jj split -i`, which interactively splits the current commit (which is your working copy).

`jj split -i` gives:

> error: unexpected argument '-i' found

Actually, maybe I'm just a complete git, but I couldn't figure out how to `git reset HEAD~` my accidental commits, `git rebase -i HEAD~6`, format `jj log` more like `git log --color --oneline --graph --full-history` (which shows one-line-per-commit), `git checkout -p` (and obviously, `git add -p`), `git show HEAD~`, refer to N-th parents, e.g. `master~5`, and a bunch of other things...

It also feels a bit weird that new files are automatically committed without being manually approved, but I suppose this might theoretically help with some of git's annoyances.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#245

Post by rcme »

arxanas wrote: post #235
rcme wrote: post #230

This seems like a really unnecessary amount of overhead. With build times often taking multiple minutes, being able to multi-task is essential. I often work on two things at once. That seems difficult / impossible with this.

What does the version control system have to do with build times and multi-tasking? I use jj in repositories with long builds, but I don't see what it has to do with that.

Every jj command creates a commit. So if you have two unrelated pieces of work you need to split all the commits created.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#246

Post by kasdi »

awestroke wrote: post #28

"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore…

> - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed

From only reading the README, my understanding is that you would just add the files to .gitignore and at the next auto commit they are removed again from the anonymous working copy commit. I agree it feels unintuitive that files are added and removed from the anonymous working copy commit, instead of not added in the first place. But since the anonymous working copy commit is largely invisible to you it shouldn’t make a difference.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#247

Post by kasdi »

josephg wrote: post #173
Karellen wrote: post #159

Earlier quoted context omitted.

Have you not ever found any value in `git bisect`? If you have a bug which is reproducible, but whose cause is complex, do you not think it's useful to be able to find the commit that introduced the bug in order to see which change caused it? If only to get a good first idea of what might need to be fixed? Currently, `git bisect` works best if every commit is buildable and runnable, in order that any commit can be au…

Yeah git bisect is great. And CRDTs on their own probably won’t preserve enough information to allow bisecting to happen - since we don’t know which points in time have working builds. One approach to preserve the ability to bisect would be to allow users to periodically mark points in time with “commits” if they want. The commits wouldn’t be used for synchronisation or merging (since we have the crdt information for…

It seems CRDTs in the limit approach a commit for every keypress. Meanwhile a commit in git is an atomic set of keypresses, to transition from one working state to another. So, in a CRDT world with a commit for every keystroke we would need to annotate sets of commits. Like “all of these commits change the title ‘hello’ to ‘world’”. Would be interesting.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#248

Post by kasdi »

KolmogorovComp wrote: post #38
Certhas wrote: post #31

Earlier quoted context omitted.

Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. Fo…

Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…

A safer way to keep temporary changes is to create a new local-only branch with a commit of those temporary changes. Then, whenever you need them, you rebase the branch on top of your working branch.

Usually these temporary changes are to config files, so rebasing shouldn’t create conflicts if you don’t otherwise modify the config file.

An alternative is to stash only those temporary changes but I find branches to be easier to work with.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#249

Post by kasdi »

TylerE wrote: post #24
ocharles wrote: post #22

Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two,…

What happens if you accidentally save a file with some sort of secret that gets sucked in?

Assuming in git you would keep it as untracked file in the working copy, I find jj’s automatic anonymous working copy commit better.

For once, it avoids the downsides of carrying untracked files around. Ever accidentally committed an untracked file somewhere deep in history during a long rebase?

Also I find it clearer what files are committed: every file - except if it is in .gitignore. Meanwhile in git you scourge through your untracked files before each commit to decide which ones you don’t want to add. Ever accidentally committed all files and forgot that there were untracked files you didn’t want?

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#250

Post by BaseballPhysics »

eviks wrote: post #240
BaseballPhysics wrote: post #233

Earlier quoted context omitted.

> It's not hard to believe, it's just the arguments don't square Have you ever had a conversation like this? Person A: Hey, what's your favourite food? Person B: Pizza. Person A: Really! Why? Person B: I dunno, I just like the taste and the whole experience of eating it. But obviously that's just my opinion, and I totally get that some people might prefer something else. Person A: Your argument doesn't square. Here,…

Instead of this irrelevant pizza example you could've tried to address the real issues with your arguments (hint: the one where you liked/prefered wasn't on the list)

I see I was too subtle, so I'll be direct: you seem to be confused because I'm not having an argument.

The question you might consider asking yourself is: why do you insist on trying to create an argument where none exists?

This is an incredibly bad habit. Arguing with people about their personal, subjective preferences when it's clear that person isn't inviting in an argument in the first place is incredibly annoying and it pisses people off. Don't do it.

Post reply on HN