I wanted to checkout an older commit to my working directory to mess around with something so I did the following command in the root of my repo:
git checkout 2aa2c5 .
But nothing happened, the # prompt simply came back. I did the command a few more times, but nothing seemed to happen. I then did:
git status
Which showed that I was still on master. I then did:
git checkout master
As I wasn't sure what was happening and just wanted to get back to where I was. It came back with Already on master
However now my website is not accessible, every single file now seems to have the permission 644? I am really not sure what has happened? It looks like although my original attempt to checkout a commit didn't do anything, it has messed with my file permissions, and/or file ownership.
UPDATE: I don't think it is the permission that is the problem. I think the problem is that all the files have changed to root for the owner and group? I was logged in as root when I did the checkout, will that have caused this?
I am new to git and Linux file permission in general, if anyone could shed some light on this I would really appreciate it.
Thanks
Permissions and ownership are really critical for web servers. If you get this wrong, the wrong people (= crackers) can read or modify your files. So make sure you understand what you're doing.
As a rule of thumb, never work as root. One silly mistake (like a flacky mouse that cut&pastes too much) can cost you the work of many hours.
In your case, it seems that the ownership of the files was changed. To fix this, you will have to delete all the files (as root; be careful - if you make a mistake, a lot more that you might ever want will be gone!)
Try to keep the Git repo (i.e. delete everything except for the .git folder) but I fear that running git as root has already messed with some permissions in that folder as well.
So your best bet might be to delete the whole tree (including the .git folder) and clone it again with the correct user.
Related:
http://www.linux.org/threads/file-permissions-chmod.4094/
http://www.linuxquestions.org/linux/answers/Security/Quick_and_Dirty_Guide_to_Linux_File_Permissions
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'm having massive issues right now trying to get a gitolite hook to go.
I've put the file in .gitolite/hooks/common/ and I have ran the gitolite setup, and when I push to a repo, nothing happens.
I have checked the permissions 755 on the file. It's owned by git. I'm fully stumped.
So far I like gitolite, however so far for me, hooks are killing me.
Try to modify the hook as published by Gitolite in your ~/repositories/yourRepo/hooks, in order to:
simplify it
have a simple echo in it
make it non-blocking
That way, you will make sure if the issue actually comes from that hook or not.
Also don't hesitate to upgrade your gitolite version to the latest one.
The OP mike tries the VREF route and finds out that:
turns out the issue was in my config file where I call the hook.
We have a group called devs and admins: I needed to make sure I was referencing the right group.
I want to add my project to a subversion repository. The project folder contains a symlink to a folder containing thousands of txt files that I don't need to add to the svn repository. I DO want the symlink-folder to show up when I checkout the code, however.
It looks like I can use svn addprop svn:ignore symlinked-folder to ignore the folder, but then I'll have to add that symlinked folder to every working copy I check out before everything will work.
Is there a proper way to do this?
Perhaps there is no way to deal with this, since a symlink is a filesystem artifact. Is there a better way to handle this situation?
CONCLUSION - EDIT
After all this investigation, I committed the symlink-folder by accident and SVN added it to the repository without adding any of the files within it. Upon checkout, everything works fine. The symlink-folder checked out and works.
I am using assembla to manage my SVN repository, so that might have something to do with this success.
The answers above are right, your symlink won't work if you check out the repository on windows.
But if you're aware of that and you don't care, you can add just the symlink without its contents:
svn add -N your-symlink
man svn add here
I believe you are correct, imagine if a user checked out your repo under Windows - how would SVN create the symlink when the underlying OS doesn't support it?
Is the target folder that you are symlinking to under version control? If so, you can make use of the svn-externals property.
You are right, it doesn't make sense to add a symlink to a repository. What would happen if someone checked out the source on a machine that didn't have access to the folder the symlink points to?
One way is to structure your repository so that you can check out the codebase without having to check out documents. E.g.:
Trunk
Tags
Branches
Documents
So you only check out the trunk or branch that you are working on, and when you require it you can check out the documents.
Alternatively, use a project management tool like Redmine to store your docs. It can integrate with svn as well so you can view your repository and manage permissions through it.
I've been using TortoiseSVN for a while and recently came back to recommitting all my changes and came across an error I've been so-far unable to solve. The only thing about my working folder C:\Development\myproject is that I've added a lot of folders/files since my last commit. What's the best course of action? Also I started an update, however that overwrote some my files, before I paniced and stop it before too much damage was done.
Try using the Clean Up command on the directory, then Update and finally Commit.
If that doesn't work, the error is moaning about deleting a directory with child items. If you know which the folder is, you can delete it by opening it in Repro Browser and delete it through that. After that, Update and Commit again and hopefully it should work. That always solves this error for me.
I cannot figure out why I get this error during check-in. I checked in successful only a few hours ago so not sure why now it's complaining
Error: Commit failed (details follow):
Error: Checksum mismatch for
Error: 'C:\sss\sss\trunk\xxxx\.svn\text-base\Header.ascx.svn-base'; expected:
Error: '3cee96f580409a1711a47541a07860dd', actual: 'a5fc0f8819b88bf32ab38d4c9a6b0654'
Error: Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout.
I got latest and also performed a clean-up which said successful so not sure what else to do.
Something has gotten out of sync or has become corrupt, and because it's in your .svn BASE directory, unless you are confident tinkering with this, you're probably better off deleting the parent of the .svn directory and then perform an update. Of course, take a backup or see if an export works before doing this, so you don't lose any changes.
FWIW, I get this sometimes with our library references where Visual Studio seems to keep a lock on some files (even though it's not compiling) and won't let me update them. I believe this is related to the xml documentation files.
Note: Subversion 1.7+ implements a new working copy approach which centralises the meta data, and it now has a single .svn directory at the root of your working copy. Your best bet is a cleanup, failing that a fresh checkout into another directory and export or file copy the corrupted working copy except for the .svn directory, over to the fresh checkout, and commit any local changes.
Looks like one of your SVN files is corrupt. First, check-in everything that can safely be checked in, and make sure to backup everything. Then fix the offending file - usually this involves deleting it from your repository. This should be okay if you're checking in a new version anyway.
I received a similar error after our project repository was moved to a new server. Try reverting your file and reapplying your changes.
I had same problem after googling for some help found articles that suggested to override the checksum in the .svn\entries file. But in that file the checksum was actually as the the expected one in the error message.
To fix the problem, I navigated to .svn\text-base dir of problem file's directory and found out that there's a copy of the file i was trying to check in changes for. I opened that file in Notepad++ and replaced it's content with content of the file to be commited and i was able to commit afterwards.
But just in case, make a backup copy of the .svn\text-base file.
I think this happened because i did an svn update before commit because it complained that my version is outdated. Anyway, it's fixed for me and hope my solution helps someone else too.
With Tortoise SVN, I choose to delete the file in Repo Browser.
First back up the problem file. and use Repo Browser delete the problem file in it, then update local folder so the file in local folder is deleted. Then copy back the backup file and Add > Commit, then I can update successfully.
The disadvantage of this method is the history of this file will be removed.
Also see another post.