I suggested that since you seemed really concerned about editing the commit that you just told it to edit. Use 'edit' all you want if your goal is to edit commits, otherwise 'new' does what it seems like you're expecting...
Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.
As a git-ist (?), if I'd ever move away from git, it would be to avoid tooling that has idioms like this (like git too has), if `jj` just gonna surface a bunch of new "bad ideas" (together with what seems like really good ideas), kind of makes it feel like it isn't worth picking up unless you don't already know git.
The idiom here is use `edit` if you want to edit a commit, and use `new` if you want to make a new commit. This works identically whether you specify the commit via branch name or commit id. I'm not sure why people are saying not to use `edit` ever. It's basically just a shorthand for staging and amending changes in an existing commit, and there's still a use case for that; it's just not "I want to see the changes on this old branch".
> The idiom here is use `edit` if you want to edit a commit
You know, you guys have fun with that, I'll continue using git which (probably) has the same amount of warts, but I already know them. I'll continue to refer new VCS users to jj, seems a lot easier to learn, but really don't have the interest to re-learn a bunch of ever-changing idioms.
I disagree with the people saying "never use edit". There are plenty of people saying conflicting things about git too, and I'd argue that understanding edit versus new isn't anywhere close to the level of wart that having to get people to agree on merging versus rebasing. Like you said though, have fun with that!
No system is perfect, but there's nothing wrong with `jj edit` and `jj new`. Both commands are completely reasonable and do what you think they would do.
jj has far fewer warts than git. You don’t have to learn every jj idiom, you just have to find a workflow you like, which you will, quickly, because it’s so easy to use. Personally I don’t know why anyone uses `edit` but if they like it then I’m happy for them.
But I have a workflow I like with git and I can’t see how jj would be better. I’m genuinely curious as to whether it would be or not, but the behaviours people are describing are not things that interest me.
For me the killer feature of jj is how much easier it makes rebasing. With git, if I knew a coworker had recently merged changes to a file I’d been working on, I would really dread syncing because I knew there was a good chance I’d get stuck in rebase hell.
With jj, you still have to deal with conflicts, but you can do it on your own time, so I never fear syncing anymore. Also, on the rare occasion that I mess up a merge, I no longer have to pull out my git sorcerer hat to fix it. I just `jj undo` and it’s like it never happened.
I think it's because it's easy to make annoying mistakes (still easy to fix with undo) with edit. And it gains relatively little over new+squash. Edit is a useful power-feature, but I think for a novice, "never use it, only use the more well understood workflow of new+squash" is a good heuristic.
`edit` is still useful; just, for ..editing (!) something, instead of viewing it.
If you have some unfinished changes at the tip and want to temporarily checkout something 2 weeks ago, you `jj new` to there (similar to `git stash; git switch whatever`), and then later `jj edit your-old-tip` to go back (equivalent to `git switch main; git stash pop`; I think `jj edit` being an extended replacement for stash-popping things is a reasonable way to think about it). (and if you don't have any uncommitted changes, you always `jj new`)
jj also has a concept of immutable commits (defaulting to include tagged commits, and trunk at origin, which it'll disallow editing as a layer of defense)
"jj new" is like "I'm going to make some changes", then you do "jj squash" to say "OK these look good enough to commit".
If you work this way you're "always" in a WIP state. And if you switch to another spot you won't lose your work, cuz it's persisted.
The end result if you work like this is you don't need stashing, since you get "free" stashing in your commit tree, which is more likely what people want (and if it's not... rebasing is easy so just move the node/`jj duplicate` it!)
`jj edit` exists but I think it's just not what people want in the default case at all. In exchange: rebasing "just works", stashing is not a thing to think about, and you don't lose your work
jj edit has good use cases, but it's not the default command you need. For instance, say you were working on some changes but had to change branches for a few minutes to do something. If you didn't manage to create a commit and want to go back to the previous staging area, you would use the jj edit command rather than jj new. It's very intuitive in my experience, something I can't say is true for managing git commits (unless you've spent years forcing it into muscle memory). I never need to run jj help. I run help commands with git all the time.
Once you get your head around it a bit, doing a new in this circumstance will be second nature, since you will have realized that a `new XYZ` in jj leads to the same underlying git state as a `git checkout XYZ` in git
If I'm understanding the thread correctly, I have a git alias to `git commit --amend --no-edit`, for exactly this workflow. When I'm hacking on something locally and want to just keep amending a commit. I only ever do this if it's HEAD though.
I go back and forth between the two approaches, but because of the whole "accidentally made some temporary changes and now it's a pain to separate/undo them because not all changes were temporary", I also usually do a jj new and then jj squash.
ah, sorry! right – the type constructor and fmap together make up a functor.
I meant functors where the objects being mapped aren't types, but type inhabitants, and the morphisms being mapped are not arrows between types, but arrows between type inhabitants. (I suppose this also has to do with "the only category in Haskell is Hask", rather than types also being themselves categories?)
> Data collected in the heat map suggest that stores with low racial and ethnic diversity, especially those located in poor communities, are more likely to unionize.
Speaking as someone who was actually there, this is a delusional view of what might have been based more on fantasy than reality.
The web _was_ P2P at the start, but it became centralized because that was more efficient and increased both value and communication. The original social networks (BBS and chat channels, Usenet, etc) _were_ distributed, but it turns out that this made them easy prey for parasitic and toxic actors and all of the available tools to prevent this imposed asymmetric costs on the recipients and did not scale at all.
Distributed systems are easy, but making distributed communication systems not suck is incredibly hard. The Internet is a distributed system that was a lot better before all of you showed up and cast us into the hell of eternal September.
Unfortunately nobody has figured out how to do decentralized discovery/recommendation. Google Search centralizes discovery for the web, Facebook centralizes discovery for the social graph, YouTube centralizes discovery for the videos, Whatsapp centralizes discovery for chat.
This is what I find so baffling - he didn't need the money and it seems like the whole Otto pursuit had a significant enough downside risk for someone who was already quite wealthy that I'm surprised he was willing to take it.
