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

Jujutsu (jj), a Git compatible VCS

tonyfinn.com

Post reply on HN
Print view View original

21–30 of 117 posts

Re: Jujutsu (jj), a Git compatible VCS

#21

Post by MarceColl »

edflsafoiewq wrote: post #18
MarceColl wrote: post #15

Earlier quoted context omitted.

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

Switch to branch for thing 1, work on it, commit, switch to branch for thing 2, work on it, commit, ...

Do you stash or create a commit with potentially partial work? What do you name that commit?

Re: Jujutsu (jj), a Git compatible VCS

#22

Post by christophilus »

MarceColl wrote: post #15
cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

I stash or commit, switch branches, make changes, stash or commit, etc. What do you do?

Re: Jujutsu (jj), a Git compatible VCS

#23

Post by mjarrett »

MarceColl wrote: post #15
cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

Isn't git-worktree designed for this kind of situation, where you could open each PR or branch in its own directory and switch your editor / other tooling between workspaces without losing state between them?

Re: Jujutsu (jj), a Git compatible VCS

#24

Post by MarceColl »

christophilus wrote: post #22
MarceColl wrote: post #15

Earlier quoted context omitted.

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

I stash or commit, switch branches, make changes, stash or commit, etc. What do you do?

that's what I used to do, now I just use jj and I dont need to either keep a set of stashes nor create superfluous commits based on when I decided to change branches

Re: Jujutsu (jj), a Git compatible VCS

#25

Post by lawn »

zug_zug wrote: post #13
ocular-rockular wrote: post #4

Earlier quoted context omitted.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas wher…

The upside with jujutsu though is that it's completely compatible with Git and you can work on the same repository with Jujutsu while your coworkers use Git.

This allows the people who want the 15% gain to have it, while not forcing anyone to do a costly migration.

Re: Jujutsu (jj), a Git compatible VCS

#26

Post by yuppiepuppie »

emacsen wrote: post #11
cupofjoakim wrote: post #2

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…

There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control. If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down,…

I get what you are saying about the nicer workflows for those cases.

However, why would the contributors to jj not just try to make git better by addressing these weaknesses?

I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined.

Yes, I know that some code bases are too far gone for major enhancements…

Re: Jujutsu (jj), a Git compatible VCS

#28

Post by [deleted] »

zug_zug wrote: post #13
ocular-rockular wrote: post #4

Earlier quoted context omitted.

But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicat…

Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas wher…

[deleted]

Re: Jujutsu (jj), a Git compatible VCS

#30

Post by MarceColl »

mjarrett wrote: post #23
MarceColl wrote: post #15

Earlier quoted context omitted.

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

Isn't git-worktree designed for this kind of situation, where you could open each PR or branch in its own directory and switch your editor / other tooling between workspaces without losing state between them?

yeah, you could do this, but it gets kind of annoying in my experience. However it is another solution, most of what you do in jj you can do in git, its just more convenient
Post reply on HN