Git: Cannot remove .php~ files - php

I use Git on a Symfony 2 project. I would like to switch branches, but I get the following message:
These untracked working tree files would be overwritten by checkout.
Please move or remove them before you can checkout.
Here a list of the files:
srv/myproject/src/mycompany/mybundle/Entity/Contacts.php~
srv/myproject/src/mycompany/mybundle/Entity/Products.php~
srv/myproject/src/mycompany/mybundle/Entity/Orders.php~
What I tried so far:
For example, I tried to do
git rm --cached srv/myproject/src/mycompany/mybundle/Entity/Contacts.php~
which gives me the message that the file does not exist.
I cannot find any "php~" files in the "Entity"-Folder. I can only see the regular "php" files.
Why do these files have the char "~" at the end of the file name?
How do I solve this problem?

Files with names ending with ~ are typically backup files made by some editors. Whether they are made by your editor, I have no idea.
They are shown as untracked (Git says these untracked working tree files...), which means they are not in the index, so you cannot give them to git rm --cached which just removes things from the index. This in turn means that—at least at this point—you have done nothing wrong. :-) Which might be reassuring, but is not really helpful.
Nonetheless, git checkout <otherbranch> is complaining that the proposed checkout would overwrite them. This means that they are contained in the commit that this git checkout would check out. That, in turn, means that someone, at some point, did something wrong, by committing them in the first place. (Assuming, at least, that they are just editor backup files that should not be versioned like this.) That could be someone other than you, meaning you have done nothing wrong, but, well, still not helpful.
This also means that they are in your work-tree right now. How they got there is hard to say, though the most obvious candidate reason is that your editor made them as editor backup files.
What you need to do
What you need to do is to move or remove these files (assuming they're editor backups, it is likely safe to just remove them entirely) so that they are no longer in your work-tree. Then git checkout will be able to put the ones from the commit into your work-tree, without clobbering the ones you already have, since you no longer have them.
What else you and/or others need to do
Committing these files is a bad idea (assuming, as always, that these are editor backups). It's kind of hard to fix this in existing commits. It's up to you and your co-workers / colleages whether to bother. However, one way or another, future commits should not contain these files.
To that end, you, or someone, must not only remove them now, you must also check out the commit(s) that have them, then remove them (e.g., git rm *~), then either fix those commits or make new commits that tell Git "they were there, and they will be in commit history, but from that commit to this new one, remove them now."
Moreover, you, or someone, should probably set things up so that Git ignores these files by default, so that it will not put them into future commits. The usual method is to add a line *~ to the top level .gitignore file. (However, once files are tracked, adding them to .gitignore has no effect until they become un-tracked by an explicit remove. This is because .gitignore is the wrong name: it's not a list of files to ignore, it's a list of files to not add, and to not complain about forgetting to add.)

remove unwanted files from git:
git reset HEAD path/to/unwanted_file
create .gitignore file and add *~ to it.
do a new commit.

Related

Wordpress files modified durning git clone (line endings, filemode or gitattributes did not help)

I'm aware certain changes may occur when cloning a repo from one OS to a different OS. However, this is not just newlines added or space formatting (but that is also happening). Chunks of code have been removed and modified completely.
I see newly added blocks, functions, .esc_attr and .esc_html tags.
I've played with .gitattributes files, set different core.autocrlf values and core.filemode values - nothing worked.
Also strange that only a subset of php files were modified. All located under Ultimate_VC_Addons.
git status image
git diff image
Any help is appreciated.
Thank you.

404 Not Found error after commit changes on PHP application Openshift

I'm having problems with my PHP applications, I have created and deleted several of them because everytime I commit changes my application crushes and it shows the "404 Not Found" error.
I'm sure there are no coding errors for two reasons:
1. The same code was working days ago, it was after wednesday that I'm getting this message.
2. The same code works on my development environment.
This happens after I commit any change, even for the first time, and after that there is no turning back, so I have to delete it and create it again.
Can anyone help me?
Thanks anyone for the help.
This is just a shot in the dark, but do you put your php files into a subdirectory called php? If so, openshift automatically sets that directory to be your document root. It would certainly result in a 404 if you navigated to the /index.html when index.html is actually one folder up.
You can read about the way that openshift automatically sets the document root here: https://blog.openshift.com/openshift-online-march-2014-release-blog/
I had this problem today because I was not commiting all of the files.
You should use:
git add -A
This will add all of the files in the directory to your next commit, without this command, only the files that already existed and were changed (apparently) would be commited.
After that, use:
git commit -a -m 'commit message'
Now your files should be uploaded to the server.
Also, use git status to see the files staged for commit and the ones that are not.

Git won't pick up changes to certain files

Have a very odd and annoying issue with Git/GitHub.
In a certain branch, any file that has the path as /views/admin/index.php, /views/teacher/index.php, /views/parents/index.php, /views/student/index.php won't detect any changes to the files no matter what. Deleting the file, removing all the code, or just making a small edit isn't picked up at all.
We are using Codeigniter v2.2.0 as the framework, if that is of any use.
This is happening through any folder with a file structure like that.
Have tried multiple different software including the GitHub native app and Sourcetree.
There is another branch we have that works fine.
Tried cloning the branch with the issue but it still has the problems on the new branch.
Any ideas that could help would be great :)
Whenever you have a file which seems to be ignore, you quickly can check that with git check-ignore:
git check-ignore -v -- /path/to/yourFile
That will help list the exact .gitignore referencing that file.
Massive facepalm moment.
I had index.php in the .gitignore, I needed to have /index.php to ignore only the index.php in the main directory.
If your using SourceTree as you mentioned, change the File Status combo from the Working Copy view to "Show Ignored".
It doesn't display ignored or untracked in "Show All".

source tree marks all file as modified

I started using sourceTree
I have a problem when I change certain files, I noticed those are files from my views folder (MVC), sourceTree marks it as:
Modified file, 1 lines changed, 1 lines removed
and when I push it to my svn the whole file is marked as changed, as in:
All the code from before my changes marked with '-'
And then all the code from after my changes marked with '+' (also stuff I didnt touch)
Any solutions?
Make sure that the config core.autocrlf is set to false, to avoid automatic eol (end of lines) conversion on all your files.
git config --global core.autocrlf false
(and re-clone your repo to see if the issue persists)
See for more "SourceTree App says uncommitted changes even for newly-cloned repository - what could be wrong?"
This sourceTree thread points out also to .gitattributes files.
The OP Asaf Maoz points to another source (in the comments), still related to eol:
the problem was in my IDE line endings settings, some files line endings was set to MAC (when I am not on MAC) and ST could not convert them properly.

PHP regex to fix hacked Wordpress site

I have a client that has multiple Wordpress installations, which he didn't keep up to date. As a result, he got hacked. While I try to find how the hackers got in, and fix the problem permanently, I'm trying to create a script to fix them quickly, automatically.
I found this script, which does what I want: http://designpx.com/tutorials/wordpress-security/
It automatically removes the <?php eval(base64_decode("aWY..."); ?> from every php file, but the regex it's using to do this, removes also <?php get_header(); ?> if it follows the malicious code.
So, what I want is to change it, so it only removes the malicious code, but not the first line of php code as well. Here's the part of the script that does the replacing:
find $dir -name "*.php" -type f \
|xargs sed -i 's#<?php /\*\*/ eval(base64_decode("aWY.*?>##g' 2>&1
What would I have to change, so it stops at the first ?>, and not at the second?
Note: I know this is a quick, temporary fix, but it will do until the client makes up his mind about which sites he wants to fix, an which to erase.
Backup database and themes.
Remove WordPress.
Remove any suspicious files.
Install newest WordPress.
Keep new WordPress files write protected
Slap so-called "administrator" for not updating on time.
Profit.
No need for some crazy scripts and whatnot. Hacks on PHP cannot work unless the file is infected. Removing it solved the problem.
And yes, it's possible to do even if you have multiple wordpress installations on the same server (WHY?!).
Apart from the comments advising a reinstall, the regex question at hand might be greediness. The .*? placeholder ought to match the shortest amount of characters, but sed might have some limitations regarding line length etc. (Not sure.)
But for constraining it further you could use [^>]* in its place:
's#<?php /\*\*/ eval(base64_decode("aWY[^>]*?>##g'
This will ensure it can't run over a closing ?>. The base64 couldn't possibly contain this anyway.
Back up everything and scan it with your antivirus. In your server delete all wp files except wp-config.php then go to wordpress.org download the latest version. Extract to your computer and upload.
Check your backup theme files for infections.

Categories