Given that the models will attempt to check their own work with almost the identical verification that a human engineer would, it's hard to say if human's aren't implicitly checking by relying on the shared verification methods (e.g. let me run the tests, let me try to run the application with specific arguments to test if the behavior works).
> Given that the models will attempt to check their own work with almost the identical verification that a human engineer would
That's not the case at all though. The LLM doesn't have a mental model of what the expected final result is, so how could it possibly verify that?
It has a description in text format of what the engineer thinks he wants. The text format is inherently limited and lossy and the engineer is unlikely to be perfect at expressing his expectations in any case.
Not yet, but the more you will insist, the more it will be. But what is your proposal for differentiating between just prompting without looking at code vs just using LLM to generate code?
The reflog doesn't capture everything. jj's oplog does.
An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
The thing to keep in mind is that Git doesn't version the file system, it versions the index. This is because a file system guy like Torvalds knows that the file system is a shared resource and no program should think it can control its state. Therefore a Git repository doesn't consists out of all the files below a directory, it consists out of everything in the index.
Git does version everything that is in the repository and all these states occur in the reflog.
> The thing to keep in mind is that Git doesn't version the file system, it versions the index.
Yes. I think that this difference is what introduces a lot of friction, both in the model, and how people use it. The divergence between the files that exist on disk inside your working copy and what's actually tracked means lots of opportunities for friction that go away once you decide that it should. That doesn't mean things are perfect, for example, by default jj only snapshots the filesystem when you run a `jj` command, so you can still lose changes from in between those, you need to enable Watchman to get truly full logging here.
> all these states occur in the reflog.
Well, let's go back to the documentation for reflog:
> Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.
It only tracks changes to refs. That is, the states that refs have been in. So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.
Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit <sha> with these args: jj rebase -r <sha> -d trunk"
The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.
This doesn't mean the reflog is bad! It's just a very specific thing. Git could have an operation log too, it's just a different feature.
> So, one big example is detatched HEADs: any changes you make to those, which still are contents of the repository, are not tracked in the reflog.
$ git checkout HEAD
$ git commit --allow-empty -m "_"
$ git checkout master
$ git reflog
a91 (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: checkout: moving from b94 to master
b94 HEAD@{1}: commit: _
28d (origin/feature, feature) HEAD@{2}: checkout: moving from feature to @
> Even for refs, there's differences: the reflog says "ref was in state x and changed to state y" without any more details. jj's oplog keeps track of not only the state change, but the reason why: "rebased commit <sha> with these args: jj rebase -r <sha> -d trunk"
> The reflog only tracks individual refs. Say we rebase multiple commits. The reflog still just says "the head of this branch was in state x and changed to state y" but the oplog says "a rebase happened, it affected all of these commits refs in these ways," that is, it's just inherently more rich in what it tracks, and does it across all relative commits, not only the refs.
68e HEAD@{15}: rebase (finish): returning to refs/heads/feature
68e HEAD@{16}: rebase (pick): message #6
7ff HEAD@{17}: rebase (pick): message #5
797 HEAD@{18}: rebase (pick): message #4
776 HEAD@{19}: rebase (pick): message #3
c7d HEAD@{20}: rebase (pick): message #2
f10 HEAD@{21}: rebase (pick): message #1
c0d HEAD@{22}: rebase (start): checkout @~6
a7c HEAD@{100}: rebase (reword): message ...
3b1 HEAD@{229}: rebase (reset): '3b1' message ...
4a4 HEAD@{270}: rebase (continue): message ...
One little benefit of the op log is that you can use a single `jj undo` to undo all the rebased branches/bookmarks in one go. If you have rebased many branches with `git rebase --update-refs`, you need to reset each of the branches separately AFAIK.
--update-refs, --no-update-refs
Automatically force-update any branches that point to commits that
are being rebased. Any branches that are checked out in a worktree
are not updated in this way.
If the configuration variable rebase.updateRefs is set, then this
option can be used to override and disable this setting.
Are you saying that that text implies that the you can undo the rebase with a single command or that all the reflogs get updated atomically? Or how is it related to the comment you replied to?
Oops. No the text implies that I can't read and answered to a claim which you didn't state, namely that --update-refs can only update specific refs. (This was given by another comment.)
Yes, this is something, that JJ provides and Git does not.
Which, the stuff you said earlier is in the reflog?
I think Git will just gain a oplog. You just need to append a commit hash to a list before each command and implement undo as remove item and checkout. The hardest thing will be race conditions, but Git already knows how to be a database.
I use a Samsung Fold because I read a lot of books/manga, and I also love its multitasking features over stock Android/Pixel. Finally I also prefer it's form-factor (roughly 3:4 unfolded screen, and a narrow front screen) over other similar devices.
But it's obviously not for everyone so I can't really recommend it to everyone. And to be honest I can't in good faith recommend any Android phone these days, I hate what Google and other OEMs have done to the ecosystem.
I'm quite bullish on Linux phones though, like the FuriPhone FLX1, the Volla Phone Quintus, and the Jolla C2 - obviously again they're not for everyone, so for normies I would recommend an iPhone, and for techies I'd suggest giving the Linux phones a try (or maybe get a OnePlus/Nothing phone and load LineageOS+Magisk if you don't mind playing the cat-and-mouse game with Play Integrity).
I have no special insights, but Sony's phones seem like a good fit. They are really easy to unlock [1], but there are virtually no mods but Lineage. Maybe because they are very stock Android and bloat-free?
They range from 300 to 1000 EUR. I personally am fond of the "lower end" and slender Xperia 5 and 10 lines and the customary 21:9 screen ratio.
Don’t Sony’s have the issue of crappier photos after unlocking because of some DRM key shenanigans? This is what I remember about my old Xperia X1C and I so left for Pixel and then eventually iOS so things would just work and last longer than a year or 2.
>you have unleashed on this world a toy more addictive than a cocaine enema.
No offense to you meant, but I wonder in general where the need for this kind of hyperbolic phrasing comes from. As it seems to be everywhere on the internet.
It was meant as a compliment, and it was not intended as hyperbolic. But since you ask...
In this case I thought it would fit with the already absurd tones exhibited in the thread. More generally, the technique is not "hyperbolic phrasing" as much as deploying a comedic angle. Comedians (especially oneliner and short-form comics) often seek ways to emphasise a visual image. The more vivid the mental imagery, that much more effective the double punch of the words and the internal visual hit.
The same technique is also occasionally used by some of the most effective tech talks; if you manage to combine a factually correct detail distillation with a punchline that invokes a strong and somewhat controversial mental image, that has a high likelyhood of being remembered.
