I was an idiot and deleted the wrong file when going to commit it to git, I've ended up losing a bunch of tested changes in my neovim config.
But as a possible saving grace I still have it loaded and open, which means since I required the particular file I know it is in cache somewhere. Is there any way I can print this cached version of it back out to a new file so I can save it as it was last loaded?
Related
Sometimes, I find that when I save a file with vim, the version of the file reverts to a previous version I had edited maybe earlier in the day or some time before the last time I saved it. The familiarity forces me to redo the work because of the file reverting to the previous version. The folder is a Github repository. Any thoughts on how I can prevent this from happening?
Are you sure you are doing :wq?
In VI/VIM, you need the w option to write the file before closing it.
So recently, all files of a python project which I had been working on for weeks got accidentally deleted, and then I emptied my recycle bin, so it is gone now.I tried to "Restore Previous Versions" of the folder it was in in windows, but it said that there were no previous versions. So I tried using a disk drill to recover those files, but i could not even find them in the list of files that it came up with. So is there a different setting/configuration on disk drive which could be preventing me from recovering those files? Do I need to use another recovery software?Or is it going to be hard/impossible to recover the file? I have been working on this project for a long time, so any help would be hugely appreciated
If you do this on VSCode while using GIT. Recreate the file in the location you deleted it, then right click on the file and select file history. You should be able to restore most, if not all, of your data.
Just happened to me, figured this might help someone else in the future.
If you don't have any shadow copies to restore a previous version from, then speicalized undelete tools are your only hope. However, if the sectors containing the deleted files' contents have been overwritten since deleting them there is a chance all is lost.
I am using Git for Windows (version 2.15, but the same issue occurs in 2.14 and I think older versions as well) and I noticed a rather annoying behavior: When I perform some basic git operations*), the modification date of the .git/objects/pack/pack-*.pack file changes. The file itself remains unchanged, but the last modification date field gets updated, which causes my backup software to think the file was changed and needs to be added to my differential backup. Because my .pack files are rather large, this increases the size of my daily backups significantly. Is there a way to prevent this behavior? That is, keep the pack file completely unchanged, including its metadata, until I perform a git gc or git repack?
Unfortunately, I wasn't able to pinpoint which operation causes this behavior. When it happened today, I only used git status, git log, git add, git mv and git commit and nothing else and the date/time got changed, but when I tried to replicate the behavior on my yesterday's backup, the date change didn't occur. I guess next time I will run Process Monitor and watch accesses to the file, but in the meanwhile, does anyone have an idea of what might be causing this problem? Thanks.
Instead of referencing your Git repo itself for your backup program to process (with the date issue), you could have:
a task which does a git bundle of your repo (that generates only one file)
your backup program would back up only that one file.
That way, you bypass entirely the modification date issue for those pack files.
You can either save and keep only one copy of a full bundle of the repo.
Or make incremental bundles.
In the end it turns out that Edward Thomson's answer explains why no "real" solution is possible. However, to facilitate my needs, I wrote a simple Windows command-line application which scans through a tree of directories, locates possible Git repositories, locates their packfiles and changes the date/time of each .pack file to that of the respective .idx file. So far it seems to run OK. I did not encounter any garbage collection issues yet, anyway. I did not release the tool yet, because I rather suspect no one else cares, but if someone is interested, I can upload it somewhere.
Apparently, someone is interested. So the program is released as of now. Not on GitHub, but still as open source, under the 3-clause BSD license. Download the binaries here: https://www.pepak.net/files/git/gitpacksync-0.01.zip
and the source code here: https://www.pepak.net/files/git/gitpacksync-0.01-source.zip
If you try to disable this then you would be prone to see subtle bugs where objects that are still in use will disappear from your repository.
You had trouble pinpointing the exact operation because every operation that adds files will do it.
This is very much intentional - Git refreshes the timestamps of objects in the database (updating the timestamp on either loose objects or packfiles) to know when an object was last written. Whenever you create a new commit, it will update the timestamp on all the files that contain objects hat were referenced.
This is important as it helps the tools that remove data (like prune) avoid race conditions: an object may be dereferenced and then re-referenced. Prune will also look at the timestamp, so by touching the file, it will not be eligible for garbage collection.
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.
Question: Today I worked with MS Visual Sourcesafe, that is to say Microsoft's Sourcecode destruction system, which has never ever saved anything, but already destroyed much.
Today I had one more of those nasty destructive episodes:
I was working on a reporting service report (*.rdl xml files).
I was modifiying a report, so I created a copy and modified it.
The original being named FILENAME.rdl
My modified copy being named FILENAME2.rdl
I finished, saved. Checked in.
It was all correct.
I switched offline, continued to work.
Later on, I deleted filename.rdl, and renamed filename2.rdl to filename.rdl
I continued working for the rest of the day offline.
In the evening I checked in, and filename2.rdl reappeared.
I thought it had copied the old version back, so I deleted filename.rdl (from local computer and sourcesafe, via the delete keyboard button in the visual studio treeview) and wanted to rename filename2.rdl again to filename.rdl.
When I tried, I realized that filename2.rdl was just an entry that appeared in the treevieww, but not on disk... It was in that very momement that I realized that I now have a problem...
I looked in the recycle bin, but nothing there.
I tried 5 different undelete programms, and shadow copy explorer [to find out that non C drive data - such as the data partition e - is not backed up by the shadow copy service automatically...], but no luck. The file is gone.
Is it possible to still retrieve the file from sourcesafe, or does it get permanently removed when one presses the delete button in VisualStudio treeview and clicks OK on deleting it from file & sourcesafe ?
So far I found this one:
http://support.microsoft.com/?scid=kb;en-us;244019&x=11&y=7
but from that it is unclear whether the file is gone.
The problem is if it isn't there, I should redo the about one hour work this evening, because tomorrow will be a busy day.
There are 2 levels of Delete in SourceSafe. When you delete the file, if you check the "Destroy permanently" option, the file will not be recoverable. Otherwise, you can go to the Properties of its parent project and recover it later.
If it's not stored under some different version or branch of your code, I think you're out of luck.
Regardless, however: you estimate this is one hour's worth of work. You already (presumably) spend some amount of time (probably an hour or two) trying to get the file back. Are you not now at the point where, even if VSS has a way to get your file back for you, you'd be better served just rebuilding it?
Short answer - definitely NO!
It can't! I tried.
But it overwrote the recreated report with a completely wrong recovered version...
Fortunately, I've forseen this, and made a backup copy of the recreated report for this case.
So I didn't spend that one hour of recreating the report in vain.
This program should be forbidden, with noncompliance to this prohibition being subject to the death penalty.