I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful about subdirectories, which is why I usually also do a "git status" again before committing.
git add . is nondestructive and reversible. I tend to do git add . and then run git status.
I’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now.
If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation.
But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.
No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita.
This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.
If your issue is that if you already have some changes to some files staged, and you have made subsequent changes to your working directory, if you git add . then it will not be possible to revert the cache to the state it was in before… well, yes, but there’s an easy way to checkpoint the state of the staged cache: git commit.
But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them.
Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.
I'm with you, though I do it differently. I have a git-status plug-in in my editor that shows me what directories -> files have been changed, and then which lines when I open them. Scanning the sidebar is the same as running "git status" first, but I prefer the visual representation.
another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git.
I've never managed to get on with any UI for basic git tasks, they always end up been slower.
I’ve been using magit lately, but I only do ‘git add .’ when it’s a very simple change. Especially in complex projects, I do some changes to isolate code or fix other issues in passing. So I stage by lines and hunks to isolate specific changes and commit them one by one. But magit is the vim of version control, so no speed issue there.
I'm learning here, but for option 2, besides the security risk, doesn't this create the possibility that users could get a broken/unfinished package any time they're updating to a recently "published" release? The property of releases being atomic seems very important.
Generally each artifact in the release is atomic, as is (and was) the case here.
You’ll never get served a partially uploaded wheel for amd64 Linux, but somebody could come back a year later and add a 2nd wheel to that release for a different architecture.
I was interested in marimo, but I became less interested when I realized that they traded off being able to assign to a variable more than once in order to allow out-of-order execution of cells.
I mean as a Jupyter user, I typically do both and just keep track of what I'm doing in my head (like a repl with many snippets I can run any time), but if I wanted to make it more predictable, I would definitely give up out-of-order execution first.
Yes I understand it's a tradeoff, but I'm saying I would prefer a different tradeoff. It would be more intuitive to me if running a cell always invalidated the cells below; this would make variable reassignment unambiguous, just like in a script, but still with all the visualization goodies of a notebook.
Just wanted to mention that you're always able to do this:
for _x in range(100):
...
This way, `_x` is detected as a throwaway Python variable. And it won't re-appear in other cells.
Also, within the same cell you can always re-assign. But you can't do that in another cell. We want to ensure that a variable is fully declared in one, and only one, cell.
> what differentiates Ente from iCloud Photos - at first (assumptive) glance, it appears redundant.
I think the point is that it's an alternative clone of iCloud or Google Photos that's not from Apple or Google. For some people, it's really obvious why you would want that, but if it's not to you, I can see why it might be more confusing why it exists.
Sure, but it's designed to minimize the chance that a quantum fluctuation could change the outcome of a computation, right? Whereas in the brain that might not be the case. A lot of the "interesting" neural activity (e.g. relating to decision making, language, etc) happen in highly sensitive dynamical regimes: on a threshold of firing, or activating one neural population vs another. (Arguably you can get the same effect in an artificial network by adding true random noise though!)
It's not implausible that evolutionary pressures made the brain robust enough to withstand parasitic signals. We know that most people think in similar, predictable ways.
I used a qualifier because (as you certainly know) people will not pass a chance to nitpick. I have no energy to argue about neurodivergent or Ramanujan, even though I still believe the basic physics of their thinking is identical. Hence "most".
My argument was straightforward to follow but if there's something unclear let me know and I'll chew it down.
Why would anyone assume that pasting an image into a CLI interface would work? The fact that this is framed as a bug is wild to me (but very cool that there is a way to do it now)
1) It isn’t a matter of literally “pasting into a terminal” (with the terminal emulator shoveling bytes into the TUI’s stdin), rather it’s “a TUI key-binding tells TUI app to read system clipboard”. No different than any other app.
2) This works on macOS, Linux and Windows, but not WSL. Sounds fair game to call this a bug, or at the very least a feature disparity.
You can be vegan as part of a health conscious diet, but strict veganism is usually motivated by ethics, not health. (That being said obviously there's more market share if you're in the intersection of the venn diagram.)
Check out optype (specifically the optype.numpy namespace). If you use scipy, scipy-stubs is compatible and the developer of both is very active and responsive. There's also a new standalone stubs library for numpy called numtype, but it's still in alpha.
Windows Terminal and PowerToys are pretty nice. The Phone Link app is convenient, and screenshots are way better (no need to paste into Paint anymore, just use snip and sketch)
The snipping tool (with all features I'm using today) was added to PowerToys more than 20 years ago. It was integrated directly into Windows 10 pretty early in the update cycle. Not sure it qualifies for "the last decade".
reply