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 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
To me it still all seems confusing. I don't have a good mental model for it.
How does it handle things like `git rebase -x 'make fmt'` which might edit each rebased commit automatically, or `git rebase -x 'make lint'` which might fail but not leave a conflict marker. I didn't see any docs for exec in jj rebase so I guess this feature doesn't work
There's also no examples for how you work out which commit has a conflict marker. It's probably obvious in jj status but it would be nice to document, as I'm not yet interested in spending the time to test it.
And I imagine it all breaks in colocated repos too (I need submodule support, and I want to use gh cli etc)
It currently doesn't; `jj run` is a command to do this, separate from rebase, which has a PR open but hasn't been merged yet.
> There's also no examples for how you work out which commit has a conflict marker
Every bit of UI shows a bright red (conflict) on conflicted changes, it's hard to miss.
> And I imagine it all breaks in colocated repos too
It doesn't break in colocated repos in the sense that the feature works when you're working with jj, but you'd want to update your submodules and use gh cli on non-conflicted things.
> To me it still all seems confusing. I don't have a good mental model for it.
>
> How does it handle things like `git rebase -x 'make fmt'` which might edit each rebased commit automatically, or `git rebase -x 'make lint'` which might fail but not leave a conflict marker. I didn't see any docs for exec in jj rebase so I guess this feature doesn't work
As a mental model, you can pretend that a commit with a conflict in it has suspended the subsequent rebase operation for descendant commits. When you resolve the conflicts in that commit, it's as if jj automatically resumed the rebase operation for the descendant commits. This process repeats until you've applied all of the rebased commits and resolved all of the conflicts (or not, if you decide to not resolve all of the conflicts).
Today, you can write something like
for commit in "$(jj log -T ...)"; do jj edit "$commit" && make fmt; done
which would also edit the commits automatically. It's probably not too hard to break out of the loop when the first conflict is detected to match the Git workflow more directly. (I can figure it out if you end up being interested.)
> There's also no examples for how you work out which commit has a conflict marker. It's probably obvious in jj status but it would be nice to document, as I'm not yet interested in spending the time to test it.
> And I imagine it all breaks in colocated repos too (I need submodule support, and I want to use gh cli etc)
It depends on the exact subset of features you need.
- jj can't update submodules, which works for some workflows but not others.
- Generally speaking, you can use the `gh` CLI reasonably well alongside jj. In jj, it's common to create commits not addressed by any branch, but `gh` doesn't support those well. You can either try to adopt your Git workflows directly and always use branches, or else you'll need to make sure to create the branch just-in-time before performing a `gh` invocation that would need a branch.
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)
Sadly in a fit of rage I nuked my .jj folder and went pure Git. I figure the files weren’t deleted, but they were easy to re-deploy. Also the jj command it self hung and I probably made things even worse and more corrupted by killing the process. It was a hot mess for sure!
I'll have to try it on a blank checkout because once I've run 'jj new' then 'jj st' does something similar to git st, but I had a situation on a fresh checkout where I know I'd saved changes in the IDE, git st showed them, but jj st came up as blank.
It may be that this only happens immediately after jj git init.
But any tool that lies to people is a huge red flag. Because while I can memorize that caveat it's presumptuous to assume that an entire team of people new to a tool will remember a footgun. That's on the tool not the victims.
With all due respect, it sounds like you might have some confusion about what happened. If you run `jj new`, `jj st` will virtually by definition show a clean working copy. You've created a new, empty revision, and as a consequence there are zero changes which have been made in that empty revision.
Asserting that `jj` "lies to people" is… probably uncalled for here. I'm not going to say it's impossible for the two commands to produce incongruent output, but knowing how they work it seems pretty unlikely. I think it's far more likely that either there was some confusion on your part (two different tabs in two separate projects?), you did something you didn't fully understand with a new and unfamiliar tool you were playing with (perhaps you misunderstood what `jj new` does?), or some other very reasonable and understandable thing occurred that falls pretty far short of "the tool lied to you".
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.
You are confused or wrong, and you are making incorrect assertions about a system "lying" to you on that basis: you can see this for yourself by typing `jj git init` (or just `jj init`) in an empty directory, touching some files, then running `jj status`. You will see a listing of the added files. The same happens if you commit these files, then make some changes to their contents: `jj status` will show the changed files, and `jj diff` will show the diff per file.
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
Give it a try, but also know that git branches and _topological_ branches are different things