How to recover lost Python source code if it's still resident in a running inter (2017)
gist.github.com
gist.github.com
Dunno if this would have helped me then, but it's interesting either way.
In the "old days", an open file was in memory, and you needed to explicitly save it with Save, or save a new version with Save As.
But now everything's flown out the window. If I open a PDF in Preview on my Mac and delete a page from it, it saves the change instantly. If I made a mistake, I can't just close it and re-open the original version. I have to use "File > Revert to > Browse All Versions..."
But it acts differently if my file is on an external drive which doesn't support MacOS file revisions, so when I close the file it gives me this scary long dialog to explicitly make a choice whether to keep my changes or revert, this is my last chance.
Oh and there's no Save As anymore, there's a "File > Duplicate" instead which is never what I want, because the whole point is that sometimes I want to save my changes in a new file but keep the old one without the changes. So I have to do a whole song-and-dance to first duplicate and then save that and then go back to the original and then revert that.
Except it all depends on the application. Some applications still have the traditional Save / Save As, while some have moved onto Duplicate / Revert.
And as you mention, some apps will update the file you have open to reflect changes on disk, while others won't.
And of course cloud apps in the browser just autosave the whole time.
So you have to keep this insanely complex matrix in your head to figure out whether you need to constantly save your work with Cmd+S or not, or whether your work will accidentally overwrite your previous version which you might have been intending to save, or whether something like a sync will overwite the work you have open, and it all depends on just on which application you're using, but whether it's a cloud version or not, and whether you're working off of an external drive or not!
It's maddening. I hate it.
And if I decide to save a copy of confidential.ppt to start a new presentation, the first saved version in the history will have all the confidential stuff in it, even if my first action is to delete them. Everyone who has access can now see it.
There's a system setting to (mostly) restore the old behavior: Desktop & Dock > Ask to keep changes when closing documents. Apple applications will still immediately update the file and disk, but it's a lot easier to discard all changes since the last save by closing without saving, and the on-disk file will be rolled back to the previous version. This setting has been around since 2012, I think one OS after they introduced the "auto-save" feature, and I've been using it ever since.
But now the different disciplines are mixed. Does it use save as, or duplicate? Does it sync with external changes on the disk, or keep your work open in memory? With apps being so cross-platform these days, they rarely respect the interface guidelines of second class citizen platforms.
Unfold the File menu. Look at Save. Now press and hold Option and look next to Save.
Why they hid it like that, I will never know — some harebrained idea to shift people away from the well-used paradigms you mention, I suppose.
On the other hand, I just tried it, and it doesn't actually help at all -- it actually makes things worse. Because it's still autosaving the whole time. "Save As..." saves my current file to a new file... but the old file still has all the changes until that point, despite never having manually saved.
So I still have to go through the whole step of reverting the changes in the first file. Only with "Save As..." it's actually harder, because the first file is no longer open. I have to go find it and open it and revert.
Ugh.
The funny thing is that the idea guy kept lying about what happened originally, but eventually confessed once everything I suggested to get access back to the repos wasn’t possible.
This is funny because normally I consider core dumps to be a barbaric relic of the card deck days. Core dumps are literally a shadow of what was going on so you have to guess.
In the mid 70s I was debugging crashed processes by attaching to them with all network connections, files etc all open so I could frob them and figure out what was going. Then again, ITS used the a debugger as its "shell" so was ultra hacker friendly. This should still be the default, but most POSIX systems can't even support it.
# handle SIGQUIT appropriately (readable version)
__import__('signal').signal(3, 1)
SIGSTOP just happens, and is mostly transparent (unless you handle SIGCONT, but who does?).I learned a valuable lesson that day about testing recovery from backups before you need them. I also learned a lesson about only running commands in a root shell when you really need to be root.
Ctrl+P → Ctrl+A → Alt+D
with `!:1-$`, where 1 is the index of the first argument you want from your previous command.So:
ls [files ...]
rm !:1-$
I personally find it faster to use bash's history expansion. But, we're talking about subsecond differences here. $ ls [files ...]
$ ^ls^rmOops.
Even if it's in the object store though, it may be hard to find; if it was never commited, it was only ever referenced by the index, and now it's completely unrereferenced. Maybe you could enumerate all unreachable blobs, diff them with the current version of the file, and manually review all the blobs where the diff size is below some threshold.
? not sure what you mean here, git definitely has a local cache. There is even a command like git rm --cached. Maybe we're getting into semantics nitpicking here, I'm talking about the file under .git/ that contains the staging area
The file you're refering to is the index; it's a list of git object IDs which make up the current staged state. It only has metadata, the actual contents of staged files are stored in the object store as blobs. Honestly, I'm not sure why some commands use --cached to mean "with respect to the index". The index is not a cache in the common sense of the word. It doesn't mirror state stored elsewhere in the repo and it's the single source of truth for current staged state.
[1]: https://lore.kernel.org/git/Pine.LNX.4.58.0508051104510.3258...
[2]: https://lore.kernel.org/git/200509020150.j821oXXM006699@lapt...
Cool!