I messed up with some commits in my project and I'd like to totally remove the commits I made, and not having any trace anymore (no revert).
Because I deleted some folders in my arborescence then restored them, but I lost all the logs that were on these subfolders and I totally need to know the modifications that have been made on these subfolders.
From the main folder, all the logs are visible, but not anymore in the subfolders
Does someone has an idea how to do it ???
You cannot remove revisions, but I think what you could to in your case is the following: Use the repository browser and go to the revision where you still had your folders, copy the required folders to some "temp" folder in the root of your repository. Switch back to the "HEAD" of the repository and move the copied folders back into your project folder.
This way you will be able to see the entire history, just make sure that you uncheck the "Stop on copy/rename" checkbox in the log window.
Related
Earlier today I was having trouble pushing changes to my GitHub. I stagged several commits but kept getting the message "nothing to commit. branch is up to date". Long story short, I used the rm -rf command to delete my .git/ folder and I re-initialized another .git/ folder. I also deleted my repository and created a new one.
I then noticed my entire code in my text-editor (Atom) had changed and saved itself. Majority of my code went back to being as it was a month ago, with a tiny bit of code that I wrote last week. I contacted GitHub support and was about to get my repo restored. Unfortunately, I had not pushed my code to my repo in a month so of course that was not helpful. I had no idea that deleting my .git/ directory would completely alter my entire project without doing a pull request.
Is it possible to undo the deletion of the .git/ folder? I've seen questions and answers regarding the deletion of other files but not the .git/ folder itself. When I use commands such as git checkout ^HEAD 'fileName', I just get an error. When I use git log I just get the commits from the re-initialized .git/ folder, as expected.
Is there anything I could do to revert everything I did this morning?
Sadly there is no easy way to bring back a folder that you deleted with rm...
rm gets rid of your files for good, there is no "Trash" folder like you would find on Windows. That's the case for your .git/ folder just like it is for any other file.
Depending on your filesystem, you could still give a try to this tutorial on Ext2fs undeletion.
Don't forget to backup your code before doing that kind of hazardous operations.
I am building a theme for NodeBB and the theme lives inside the node_modules directory. Pulling in from master last night I have a new .gitignore my file had ignore all node_modules except for my theme, well since this is a new .gitignore it didn't track my changes.
Then I made changes to my theme without it being tracked. I decided to merge with my repo, after some conflicts took a step back then did npm prune now this pruned my theme, I spent the last hour making changes that I am not sure I can get back.
My question is since the folder was not being tracked is it possible to undo the npm prune and recover the theme within node_modules?
Sadly, I think you won't be able to get your files back.
If you added the files or the directories to .gitignore, then git wasn't tracking them. So you cannot get them back with git, unless you used to have them in the repo, but even if you did, the latest changes that you lost would not be part of the repo. Sorry for the negative answer.
However, all is probably not lost right now. If you immediately unmounted the file system or remounted it read-only as soon as you realised you deleted your theme, you could always try a file recovery tool such as photorec.
I have a copy of a Web site checked out with Tortoise SVN. We are making a Spanish version of the site, and I need to copy the en/ directory, paste it in the same directory, rename it es/ and then commit it back to the repo. How do I do that?
Right-Drag the folder from the right list view in explorer to the same folder in the tree view on the left. When you release the mouse button, the drag context menu is shown where you will see multiple entries added by TortoiseSVN. One of them is SVN copy and rename. Or you could just use SVN copy - TortoiseSVN will detect that the file/folder already exists and ask for a new name.
This has been plaguing me for a week.
SVN keeps telling me that a certain file "does not exist in repository".
Fine. Let's just delete it. Forget about it. Ignore it. Whatever. I don't really care about this file (especially if it continues to fail the nightly check-in).
The most bizarre part? A "restore" will actually RESTORE the file from the repository, so its there (corrupted, maybe?).
...and this has to be the icing on the cake. If I delete the file through Windows Explorer, SVN will RESTORE the file from the repository, and right after that state that it doesn't exist in the repository. WTF?
Does anyone have a clue how to get rid of this?
I've already tried clean-ups, reversions, deletions and anything else imaginable, but this one has me stumped.
Thanks for any tips you might have...
It seems most likely that you have corrupted your local working copy, e.g. by moving folders or some other manipulation that you did with windows explorer but should have done through the TortoiseSVN context menu. The information inside the .svn folders now no longer matches the state of the working copy, which is confusing Subversion.
To fix this, delete the parent folder ("Originals") in your working copy with windows explorer (NOT with TortoiseSVN). Then do a TortoiseSVN "update" at the root of your working copy. This should restore the folder in working order.
Another option is to discard your working copy entirely and do a fresh checkout.
Note that the next release of Subversion (1.7) will reduce the opportunities for corrupting your working copy by centralizing all metadata in a single .svn folder at the root.
I've had similar problems with corrupted working copies. Sometimes the working copies have a lot of pending changes but unable to checkin. To resolve this, I use the following approach (svn 1.7+):
Checkout a fresh working copy into a new directory (path2)
In the fresh working copy, if the offending file is there, delete it if needed.
Commit the fresh working copy
In the fresh working copy, delete everything except the .svn directory
Copy everything from the old working copy except the .svn directory into the fresh working copy.
Commit the fresh working copy again
Delete (or backup) the old working copy
Rename the fresh working to the old working copy (path2 to path)
I had faced a similar problem wherein i had a folder, for example "FolderA" which consistently shows in svn update even though I had deleted it.
It would not even show in the folder list but svn would still recognise it as if it exists.
I followed below steps:
1.Create same folder name for which svn was giving error in the same file location
2.Added it to svn checkout. Since it gave conflict errors, i resolved it using the svn option to resolve.
3.Deleted the folder and committed my svn.
Error was resolved
After I add and commit changes from my VS2008 solution folder, I have noticed that the the exclamation mark on all files and folders changes to a checkmark after the commit is completed to SVN repo, except for the file which is in the same folder as the folder. Even after I hit Refresh or perform SVN update and then Refresh, the exclamation mark stays. Is the problem between the chair and the keyboard or a known SVN issue. Please note that I am using Tortoise SVN 1.6.9 on Windows. Thanks in advance.
Firstly, you should notbe adding *.suo files to source control. It is bad practise, especially if you have multiple users working on the same project or solution. You should add all *.suo files to the SVN ignore list.
That said, the problem you describe is fairly common with Tortoise SVN and SVN in general, in my experience. Sometimes Tortoise SVN / SVN can get a bit confused, the .svn meta-data folders can get out of sync with the server copy, or even corrupted. To solve this problem, your working copy needs to be 'Cleaned up'.
Try the following:
Select the folder of your working copy in Windows Explorer, then
Right Click - Tortoise SVN - Clean Up.
If this doesn't work immediately, try multiple combinations of updating your working copy, then cleaning it, then updating again. This usually fixes the problem.
Read here and here for more.
The problem is also quite often with Windows/Windows Explorer itself. Refreshing of the SVN status icons doesn't always happen immediately. I believe it is a problem/limitation of the combination of Windows Explorer and the Tortoise SVN shell plugin.
Please do this
Directory ->Right Click->Check For Modifications -> On Modifications(select all)->Right click -> "Commit"-> In the bottom pane click "Refresh". Now it should have removed that warning sign.