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.
Related
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?
I was coding earlier and decided to not commit. When I revisited the project later in the day, I went to Source Code/Discard All Changes. I didn't like the direction I was taking the project, so I figured I would discard changes and then reclone my project into another folder to get back to my original state. I've been working on this project for a few weeks now, and this one particular file has been part of the project since the beginning.
It's showing up in my project tree on the left side of XCode, but it's empty. When I look in the folder, it's straight up missing. No problem, I'll restore from github. This is where the problem is. It doesn't show up in any of my commits. I don't see this file ever existed, but if I look at some of my commits, I see references to the file. Is there any way for me to recover this file, or do I need to start coding on it again? This really sucks... :(
I've done 'git log --full-history -- path/to/file' and it doesn't find anything at all. I do the same for a known good file, and it shows the file. This file isn't in my history at all. I thought that was the whole point of git was to be able to go back in time if something happened?
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 this problem with ankhsvn:
i have the solution up to date , but not its unique project . When i try to commit i got this error
when i click into Show changes i have some changes in a temporary file integration_finale.csproj
So, What are the reasons of this error? How can i fix it?
The csproj file is not a temp file. It governs your project set-up and settings for references, paths, build details etc.
From how it appears this conflict can (probably) use local as it appears the rest of the file is correct (at least from the image). It appears that the change is just that the SpecificVersion flag for he reference has been changed to the default setting.
Now you should backup this file and confirm the rest of the file is correct. If you corrupt this file you will have to rebuild the project file (csproj).
'Clean' solution via AnkhSVN and get update again
if above does not works then I would suggest you to take backup of your current .csproj file. Then update the file to latest commit version on svn. After which you can merge code and commit your changes.
better use TortoiseSVN
I use ankhsvn, and I know that it has a few bugs. To diagnose (and better handle conflicts too) this kind of problems I use also TortoiseSVN.
I inadvertantly did a very stupid thing last night. I have been working on an iPad project for a couple of months and (even more stupidly) do not have a backup. By right-clicking on the project in XCODE, I mistakenly clicked "Discard Changes"
(stupidity reigns again) I did not have any commits since the initial and when I did the Discard Changes, it seems that it went all the way back to the initial commit, which if I am looking at things correctly looks like each file is as it was the very first time it was saved.
My question is: Is there a way to recover my work? Is it in the .git directory? Is a copy stored elsewhere? or as a last resort, any chance to recover some of the source text with an un-delete utility?
Thanks,
Bob
For little clarification.. one can put back files from the trash as discard changes sends the file in the trash
Answer copied from How to undo xcode discard all changes if not committed
Quit Xcode.
Open the file you wish to bring back your lost changes to using TextEdit.
Go to File -> Revert To -> Browse All Versions...
Scroll through the available versions. Hopefully you will have many available to choose from.
Select a version and hit Restore.
Follow 1-5 for all necessary files.
Launch Xcode. You should now see the M next to these files in Project Navigator indicating they include uncommited changes (the changes you previously discarded).
Completely new files you may have created and were discarded can be found in the Trash.
Also a small piece of advice. If you are in need to discard changes, prefer using Source Control -> Discard Changes by right clicking on files in the Project Navigator, instead of Discard All Changes which might give you all kinds of trouble.
Have a nice day. :)
Well luck was on my side after all. As it turns out, when I did the Source Control > Discard Changes operation, it did not make any changes to the source code save in my project directory. I was able to start a new project and added the files back in. Once I did that I was able to compile and run my project in the simulator just as it was before the incident. I now have a backup as well as committed the changes in git.
You have a hope of fetching this code if you "pushed" & committed your prior-to-discarded changes into your local git repository. Or if you're using MacOS's included Time Machine or some other automated backup solution.
Aside from that, you might be hosed.
If you're on Lion or later, you may have Time Machine backups even if you don't have an external drive. As of Lion, Time Machine will take 'local snapshots' of files; this is how they support the "Versions" feature that lets you go back to previous versions of your files.
If you didn't have Time Machine turned on, though... you may be out of luck.