|
| ▲ | kps 9 hours ago | parent | next [-] |
| I think you have somehow picked up an overcomplicated workflow, and this is case is actually something that `jj` is much better at. If I'm in the middle of working on <foo> and someone asks about <bar>: `jj new <bar>`. When I'm done (and do whatever I want with those new changes in <bar>, including deferring deciding what to do), I just `jj edit <foo>` and I'm back exactly where I left off. It's a bit like `git stash` without having to remember to stash in advance, and using regular commit navigation rather than being bolted on the side. |
|
| ▲ | MrJohz 6 hours ago | parent | prev | next [-] |
| I think the right intuition to have with jj is that `jj st` should show an empty change unless you are actively working on something. `jj commit`, as mentioned below, is a good example of this - it automatically creates a new change and checks it out. The "squash flow" also does this well - you use the branch tip as a staging area and squash work into other changes on the branch as you go along. Either way, once the work is finished, there's an empty change at the tip of the branch. This is also supported by jj implicitly - whenever you check out a different commit, if the change you were on is empty, has no description, and is the tip of a branch, it's automatically deleted to clean things up for you. |
|
| ▲ | icorbrey 10 hours ago | parent | prev | next [-] |
| Fwiw I generally solve this by using `jj commit` instead of `jj desc` unless I'm specifically targeting something that isn't my working copy. Technically it violates the "we want commands to be orthogonal" guideline we use to write Jujutsu (otherwise this would indeed be `jj desc; jj new`) but as a habit it's never let me down |
| |
| ▲ | tom_alexander 10 hours ago | parent [-] | | Ah, thanks! That's a command I haven't learned yet, so I'll have to check it out. I learned jj from the tutorial that was posted and I don't think it covered `jj commit` at all. | | |
| ▲ | steveklabnik 10 hours ago | parent [-] | | I didn't cover it for various reasons, but I think it's good to teach now that I've had more time to consider this sort of thing, so the next iteration will likely start by beginning with jj commit. | | |
| ▲ | saghm 9 hours ago | parent [-] | | In a pure `jj` model, commit might not even be necessary as it's own subcommand (since you could easily define an alias for `desc` followed by `new`). We're still living in a world where most people who would consider adopting `jj` are git users currently, so I wonder if starting with `commit` and then following it up with an explanation of "here's how you can change the commit message without needing to make a new commit" and "here's how you can make a new commit without changing the name of the current one" would end up fitting people's expectations better. | | |
| ▲ | steveklabnik 8 hours ago | parent [-] | | Yes, I do think that the latter is correct now. I tend to learn "bottom-up", so I like the new + describe as a way of learning, but people want to jump in and get going with tools, so commit fits that expectation better. | | |
| ▲ | saghm 2 hours ago | parent [-] | | I'm the same way. I've learned over the years that this ends up being somewhat uncommon though, and one of the harder but more rewarding parts of helping people learn is figuring out where they're coming from and meeting them there. (I'm positive this is something you've been well aware of for a while though, probably longer than me!) |
|
|
|
|
|
|
| ▲ | ersatz-matty 10 hours ago | parent | prev [-] |
| From your "polluted" snapshot, you can run `jj commit -i` and use the TUI to select only what you want. |
| |
