Hacker News new | ask | show | jobs
by jjfanboy 488 days ago
Er, well, never type `jj edit` and this will never be an issue?

I exclusively move in a jj repo with `jj new` and `jj squash` or `jj squash --to <rev>` as appropriate. I've been using it 8+ hours daily for months and have never, ever even thought of having this issue.
1 comments
porridgeraisin 488 days ago
I find it quite funny that this is exactly the kind of the thing "just don't use ... 8+hours daily ... Never had issues ..." that people who remain with git say.

And now people are saying it for jj.

Endless cycle it seems, with every new tool.

link
jjfanboy 488 days ago
`jj edit` is specifically and exclusively for mutating existing commits.

Thus, if you're worried about mutating existing commits, don't use it.

What exactly is so hard to understand here? You're not making the gotcha point you seem to think you are - it's not like it's some common command that is hyper-overloaded and has to be used specially.

Just another example of the usual HN skepticism that isn't even skepticism, it's just smug ignorance. It's so exhausting. But sure, the countless people that keep claiming its the single biggest tool improvement in some time are just idiots? suckers? hype-beasts? making it up? or what?

Like, the irony of you assuming that it must be as convoluted and hard to use as git is just... awesome. I love the Git defenders that literally can't fathom that there is actually a better mental model or simpler tool, and can't even be arsed to try it and see.

link
eproxus 487 days ago
With JJ you can even override the ref spec of what should be considered a mutable commit. Feel free to set it to all commits and JJ will not allow you to mutate anything unless you pass the --ignore-mutable flag.

For example, I've configured it for me to make any commit by anyone else mutable regardless of branch:

    [revset-aliases]
    # To always consider changes by others immutable:
    "immutable_heads()" = "builtin_immutable_heads() | (trunk().. & ~mine())"
link