6 ms·

I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so

I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking.

do_not_redeem 1y ago
> Working copy as commit means you have no quality control The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.
Filligree 1y ago
> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. Sorry, but saying this implies you haven't tried it. :-) Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'. Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream. You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.
- ants_everywhere 1y ago
  Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. The FAQ suggests this isn't possible and that you should work around it by using a separate branch and then merge into your target branch, which is a pretty ugly workflow. Their GitHub branches are a mess of auto-generated strings, which suggests to me that this problem isn't just an abstract concern but is a form of technical debt that the jj devs are currently piling up.
  - stouset 1y ago
    > What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. Yes, it's "committed", but that doesn't mean all that much. I have the fsmonitor feature enabled that continually watches my repos as I edit files in them. This means that over the course of a coding session, the revision I'm working on has probably pointed at dozens or more ephemeral underlying git commits. Those are only kept around for the purpose of the evolution log, which lets me look back at my edit history throughout the day even without having interacted with the repo. When you're ready to "finalize" your work, you have two common workflow options: you can `split` the out parts you want to keep as one consistent commit, which dumps the rest in a subsequent revision. Spiritually this is equivalent to `git add -p`. Alternatively, you can create an empty "staging" revision before your "working copy" revision and `jj squash -i` pieces you're happy with into there. In practice, many people use both. I generally do the former for new work, and the latter to make changes to earlier work. Thinking that `git add -p` was absolutely a deal-breaker is the main reason I passed over jj for so long. I care deeply about maintaining a clean commit history with small, isolated, and individually-tested changes. I thought jj would make that harder due to not having a staging area. I was wrong. It is actually far easier to be principled about your commit history with the tools that jj gives you.
    - 1y ago
steveklabnik 1y ago
> I'm confused what this is? jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to. > Is it just a git frontend for people who are confused by git? I used git since before github existed. I considered myself a git lover before I found jj. I will not be going back to git. The thing is, jj is both simpler and more powerful than git, at the same time. People who are confused by git may like its simplicity, but I like its power. > It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. You already got some replies on this one, so I'll leave that to them :) > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. This is an understandable misunderstanding. The right way to think of it is "the index is also a commit." A common way of working with jj is to do something like this: Imagine I am working on adding some feature x to my codebase. I'll first make a change, and give it a description: jj new -m "working on feature x" trunk Working copy (@) now at: lqqlysul c6756b49 (empty) working on feature x Parent commit (@-) : ylnywzlx 8098b38d trunk | (empty) foo Now I will make a new empty change on top of that: jj new Working copy (@) now at: pxrvoron c823d73a (empty) (no description set) Parent commit (@-) : lqqlysul c6756b49 (empty) working on feature x Now, @- is the change that I intend to push publicly, but @ is my index. Say I add foo.rs: touch foo.rs Now, when I run `jj status`, jj takes a snapshot, and it now lives in @: jj st Working copy changes: A foo.rs Working copy (@) : pxrvoron ba7ad8c6 (no description set) Parent commit (@-): lqqlysul c6756b49 (empty) working on feature x We can see the diff here with `jj diff`: jj diff Added regular file foo.rs: (empty) So, let's say I'm happy with its contents. I want to stage it into my final commit. I can do this with `jj squash`, which by default takes all the diff of @ and puts it into @-: jj squash Working copy (@) now at: pxkqmsww 9f7e1ef2 (empty) (no description set) Parent commit (@-) : lqqlysul 41dc1531 working on feature x Now that change is in @- instead of @. we can see that by passing -r (for revision) to `jj diff`: jj diff -r @- Added regular file foo.rs: (empty) I don't have to move the whole change; I can do the same thing as git add -p by using jj squash -i, and only move the portions of the diff. What's the advantage here? Well, because the index is just a commit, I can use any tools that I use on commits on the index. There's nothing like `git reset` needing to have `--hard` vs `--soft` vs `--mixed` to deal with index behavior: everything is in a commit, so everything acts consistently. jj makes it very trivial to carve up commits into exactly what you want. It is far easier and more powerful than using the index for the same purpose. > The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking. IMHO, commit pollution is more due to the pull request workflow than git itself, though I do think that git doesn't do that much to help you. jj can help with this kind of thing, but also on some level, it can only do so much.

do_not_redeem 1y ago

> Working copy as commit means you have no quality control The working copy doesn't get automatically pushed to GitHub or anything crazy like this seems to be implying. You review/curate your commit when you give it a description.

Filligree 1y ago

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. Sorry, but saying this implies you haven't tried it. :-) Jujutsu commits aren't equivalent to Git commits. They're implemented with a mixture of Git commits and the Git working tree, yes (if you use the Git backend!), but when you see 'commit', you should read 'named diff'. Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream. You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. jj makes that much MUCH easier than rebases and history edits could ever be with git. Most of my nontrivial jj work involves at least three or four commits at some point, everything from experiments to documentation branches, which with git I would have needed to awkwardly fit into stash or inconvenient throwaway branches.

ants_everywhere 1y ago
Thanks, can you link me to their perforce backend code? I don't see the string "perforce" or "p4" anywhere in the code and it's not coming up on search. > You can and should rewrite the un-pushed commits to clean up history prior to pushing changes upstream. My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. The FAQ suggests this isn't possible and that you should work around it by using a separate branch and then merge into your target branch, which is a pretty ugly workflow. Their GitHub branches are a mess of auto-generated strings, which suggests to me that this problem isn't just an abstract concern but is a form of technical debt that the jj devs are currently piling up.
- stouset 1y ago
  > What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready. Yes, it's "committed", but that doesn't mean all that much. I have the fsmonitor feature enabled that continually watches my repos as I edit files in them. This means that over the course of a coding session, the revision I'm working on has probably pointed at dozens or more ephemeral underlying git commits. Those are only kept around for the purpose of the evolution log, which lets me look back at my edit history throughout the day even without having interacted with the repo. When you're ready to "finalize" your work, you have two common workflow options: you can `split` the out parts you want to keep as one consistent commit, which dumps the rest in a subsequent revision. Spiritually this is equivalent to `git add -p`. Alternatively, you can create an empty "staging" revision before your "working copy" revision and `jj squash -i` pieces you're happy with into there. In practice, many people use both. I generally do the former for new work, and the latter to make changes to earlier work. Thinking that `git add -p` was absolutely a deal-breaker is the main reason I passed over jj for so long. I care deeply about maintaining a clean commit history with small, isolated, and individually-tested changes. I thought jj would make that harder due to not having a staging area. I was wrong. It is actually far easier to be principled about your commit history with the tools that jj gives you.
  - 1y ago

steveklabnik 1y ago

> I'm confused what this is? jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to. > Is it just a git frontend for people who are confused by git? I used git since before github existed. I considered myself a git lover before I found jj. I will not be going back to git. The thing is, jj is both simpler and more powerful than git, at the same time. People who are confused by git may like its simplicity, but I like its power. > It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. You already got some replies on this one, so I'll leave that to them :) > Some of the design decisions are also not great. Working copy as commit means you have no quality control. The whole point of a commit is that... you commit it. So now you need a separate repo or filter to remove the worthless changes from the ones that you actually intend to commit. Bad commits polluting git histories is already a big problem. This is an understandable misunderstanding. The right way to think of it is "the index is also a commit." A common way of working with jj is to do something like this: Imagine I am working on adding some feature x to my codebase. I'll first make a change, and give it a description: jj new -m "working on feature x" trunk Working copy (@) now at: lqqlysul c6756b49 (empty) working on feature x Parent commit (@-) : ylnywzlx 8098b38d trunk | (empty) foo Now I will make a new empty change on top of that: jj new Working copy (@) now at: pxrvoron c823d73a (empty) (no description set) Parent commit (@-) : lqqlysul c6756b49 (empty) working on feature x Now, @- is the change that I intend to push publicly, but @ is my index. Say I add foo.rs: touch foo.rs Now, when I run `jj status`, jj takes a snapshot, and it now lives in @: jj st Working copy changes: A foo.rs Working copy (@) : pxrvoron ba7ad8c6 (no description set) Parent commit (@-): lqqlysul c6756b49 (empty) working on feature x We can see the diff here with `jj diff`: jj diff Added regular file foo.rs: (empty) So, let's say I'm happy with its contents. I want to stage it into my final commit. I can do this with `jj squash`, which by default takes all the diff of @ and puts it into @-: jj squash Working copy (@) now at: pxkqmsww 9f7e1ef2 (empty) (no description set) Parent commit (@-) : lqqlysul 41dc1531 working on feature x Now that change is in @- instead of @. we can see that by passing -r (for revision) to `jj diff`: jj diff -r @- Added regular file foo.rs: (empty) I don't have to move the whole change; I can do the same thing as git add -p by using jj squash -i, and only move the portions of the diff. What's the advantage here? Well, because the index is just a commit, I can use any tools that I use on commits on the index. There's nothing like `git reset` needing to have `--hard` vs `--soft` vs `--mixed` to deal with index behavior: everything is in a commit, so everything acts consistently. jj makes it very trivial to carve up commits into exactly what you want. It is far easier and more powerful than using the index for the same purpose. > The biggest problems with git IMO are it scales poorly and it encourages commit pollution. Presumably jj isn't trying to tackle those problems, which is totally fine. But I am confused about which problems it is tackling. That's why I'm wondering whether it's just a frontend that the author finds more to their liking. IMHO, commit pollution is more due to the pull request workflow than git itself, though I do think that git doesn't do that much to help you. jj can help with this kind of thing, but also on some level, it can only do so much.