necauqua

With what you described it sounds like jj is _literally_ exactly what you need, lol

Give it a try, but also know that git branches and _topological_ branches are different things

There's an anti-footgun heuristic that asks "are you sure", basically, if the file about to be tracked is >=1mb, saved a lot of asses a lot of times.

But also, if it is such a showstopper, you can disable auto-amend of _new_ files with snapshot.auto-track=none() config (or even something funky like src/*) - and recently jj status finally started showing untracked files too, it's very usable

It's hilarious that there are people who "don't get what problem jj is trying to solve". It seems like they just use git so little, barely for more that linearly committing, so they are not aware of it's shortcomings that jj often elegantly fixes.

I guess you don't use anything that's not preinstalled on your OS distribution then, lol

Jesus, what a hater Maybe one day you'll become self-aware

I guess you could question the specific example, but to me the question sounded like "why would you do rebases".

Like, for various reasons?.

The point was that it's way easier and way safer to do rebases in jj, and it straight up allows to do complex stuff like the mentioned example easily and inderstandably, idk

??.. wdym why, what?.

Also this is just an example, there are a lot of very complex (from the point of git) things that are trivial like that in jj.

Although if you're asking "why would we do that" then I don't even know what to tell you lol

It's very obviously miles better because there's no global rebase state?.

So you can just leave the conflict there an go work on something else then come back.

Also it's not sequential like --continue you've mentioned.

Also you can rebase the conflicting commits themselves, and by doing so potentially resolve the conflict and the resolution will propagate.

For example manually undoing the rebase while useless (there's jj undo after all) shows that.

You can set `snapshot.auto-track` config to "none()" (which is a fileset, so you could actually have something like src/* there).

That way, only files that were already present in the wc commit are amended, and new files are kept untracked until you explicitly `jj file track` them. And jj status finally fully shows them in the main branch too (it's broken in the v0.26 release sadly)

While I understand your predicament, consider not giving up on jj just yet because of this.

It is _exceedingly_ hard to lose files in jj, it's actually emotionally frustrating reading the line "most important thing [..] is to never ever delete file" because that's the whole shtick in jj with the oplog and whatnot - so something like nuking secrets completely from a jj repo is a bit of a chore.

Can you file a bug at least? A repro of some sort?. Or at least show us what is it what you did, `jj op log` might be enough to deduce what happened.

Also check out `jj op log -p`, your files might very well be in history, especially if, as you said, jj status took a long time (presumably snapshotting those files that got lost)

In git terms (this is an analogy that is a bit wrong, but useful here), doing `jj new` after making some changes is the same as doing `git commit -am ""` then.

Would you expect `git status` to "show you the changes, full stop" then?.

Where the hostility is coming from, ugh

Why is it so hard for people to even consider for a minute that they might be wrong or confused - nooo, this tool that was in development for years by at least one full-time google employee with a decade of mercurial dev experience and a ton of contributors, and that is loved by a lot of people already for it's simplicity and functionality - definitely failed in such a basic task, it's not you misunderstanding some basics in how it works, definitely, "full stop".

Another thing is that you might have set a `snapshot.auto-track="none()"` config and never told us, which is an opt-in way to disable autotracking, and which `jj st` does not support fully (if at all in released version) yet - then you totally "opted in" being lied to, sorry.

It's `jj status`?.

Wow, you really just looked at a screenshot, got mad, and then went to write this shallow hate message.

> my bane of "modern" CLI applications

Ok boomer, I guess you're also a Rust hater too - because I love that every last CLI written in Rust is not garbage because clap is so good and so ubiquitous

All the colors and unicode graph can be configured and disabled through config and CLI flags, and the default pager is less which supports NO_COLOR and piping and everything else that less does.

It literally has an extensive template system as one of the features to make the log output ANYTHING you would want:

adjust some colors that you hate? sure (also there's a config for color names that are used in templates, for colorblind or contrast adjustments etc)

add/remove/adjust some info (that you hate)? sure

just list full commit ids to be machine-readable that match some revset? - absolutely

Man, why do I feel so second-hand embarassed from reading this dumb ignorant reply, lol