I need to reverse a patch file. To be more precise I would like to make all the pluses minuses and all the minuses pluses. It is not my patch, it is not my code so I don't have git history and commits. So instead of manually writing all the lines, how could I make a reverse patch file that should work and put back what was removed and remove what was put into code with that patch?
Related
To add a path to search in for header files, you can feed an -I argument to configure. However, the added path will then be searched in before the default ones, effectively overriding the default ones in case of duplication. I want a path to “fall back to” when headers are not available in default paths while still using default headers as much as possible. Is there any way to specify a path to search in for headers after the default paths? Or, for the ultimate purpose, is there any other way round? Like
Setting the “search order” for paths; or
Specifying the additional path with “low priority,” etc.
Using gcc you might be successful using -idirafter. Keep in mind though that configure may modify your search path with -I on its own, for example when it finds a library in a custom location, it might (and probably will) add -I for this location to all subsequent tests and final compilation, which might still include other packages from this new location if they are available there instead of default location.
As you stated specifying the path using that flag will add it to the beginning of the include/library path. One possible work-around would be to add your custom library paths to your ld.so.conf file. This article goes over Library path in gcc various commands/environment variables to help you do so.
By default, /etc/ld.so.conf refers to the content of all files in the directory /etc/ld.so.conf.d. You can look into the directory to control the configuration.
Previously, I had WordPress' wp-config.php committed; since then, I've now ignored this file in .gitignore, which is fine.
Unfortunately - now when pulling to live, it provides this error:
M .htaccess
U wp-config.php
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.
Before this issue happened, I had an issue with pulling where it said I had uncommitted changes with these files - so I let it overwrite them, then I uploaded the actual files manually via FTP, which caused this new error.
I want to keep the files in their current state on the live server, but get around this error now and in the future.
What is the process of being able to pull the latest changes with this?
UPDATE - I'm adding an answer to a question posed in comments, and clarifying a related point
First let's clear up a little confusion: This error has nothing to do with putting the file in .gitignore. In fact, since the file is present in the index, .gitignore has no effect whatsoever on the file.
Before this issue happened, I had an issue with pulling where it said I had uncommitted changes with these files - so I let it overwrite them
You may need to be more clear about what commands you issued and what output you saw, because this is where your trouble is coming from.
When you say you "let it overwrite them", what does that mean? git resists overwriting local changes (especially uncommitted changes)...
I'm guessing what really happened is that git tried to merge changes from the remote repo into your local changes for those files, but had merge conflicts on wp-config.php.
And most likely it's still in a merging state, which you'll have to resolve before you can move on. If you say git status it will likely tell you that you're merging, with some changes "to be committed" (likely including the .htaccess file) and some "unmerged paths" (likely including the .php file).
If you have the .php file looking the way you want it in the work tree, then you can say git add wp-config.php and then git commit which should cause the merge to complete. (More generally, you have to get the file looking how you want it in the index, and do this in a way that tells git the conflict is resolved; and then you can commit to get out of the merging state.)
Now in comments you ask about whether this will put the file "back" into git. And that comes down to what it means to "have the .php file looking the way you want it".
If you never want git to provide the .php file (even during a fresh clone), then you need to remove it from the index and subsequent commit.
You could (at least temporarily) remove the file from the working tree and then do a git add (as noted above). Or, if you don't want to affect your working tree version, you can
git rm --cached wp-config.php
directly making the index look "how you want it". At this point it becomes possible for your .gitignore entry to help you avoid accidentally reintroducing the file.
If what you mean is that the file should be there, but only a default version should be in the repo (not taking any changes that might be made in the working tree), git won't do that. You'll have to get where you're going a different way. For example you could put the file in the repo as wp-config.php.default and ignore the wp-config.php path. After cloning the repo you would then copy the default file, and any local changes would be made only to the ignored copy.
I have some process that creates text log files, and some backup server.
I want to move text log files to backup server (with remove source file). And on next rsync start if there is log file with the same name - append/concatenate it with previously moved file.
rsync -av --append --remove-source-files user#server1:/source/ user#server2:/destination/
And everything works great except - if there is file with the same name on source and destination, and destination/receiver have longer file than on source server - it's skipped. How I may disable this --append's file length verification? I want simply append files with the same name with no restrictions.
The append option doesn't work like that.
From the man page:
This causes rsync to update a file by appending data onto the end of
the file, which presumes that the data that already exists on the
receiving side is identical with the start of the file on the sending
side.
So, if you "append" a 2KB file to a 1KB file, the end file with be 2KB, and the first 1KB of the larger file will be discarded. Conversely, if you "append" a file of equal or smaller size, then the whole file will end up getting discarded.
By passing the --append option you're basically promising rsync that you know the start of the file will never change.
But, if you delete the file then the start of the file has changed. Likewise, logrotate will make bad things happen.
Conclusion: --append does not play nice with --remove-source-files.
The --append-verify option will solve the logrotate problem, but won't solve your problem because it will still discard data (albeit different data).
I use Git and GitHub to push changes I make on my local web development environment to my GitHub account and from there I pull these updates to my live production site. I am working with WordPress, so what I have done is .gitignore the wp-config.php file as my productions site has its own unique wp-config.php file with its own respective database credentials. As I am git ignoring this file, when I pull to my production site it gives me the following error:
error: Your local changes to the following files would be overwritten by merge:
wp-config.php
Please, commit your changes or stash them before you can merge.
Aborting
How do I prevent this wp-config.php file from being overwritten (more specifically deleted) when I do a git pull?
This is your machine specific config file. For such case its better to use build tool. For you its better to create your custom configuration on a special file my-config.php and include it in wp-config.php. Also ignore my-config.php in .gitignore. Now you'll never see any problem like this.
What you will see is my-config.php file not found error. And write it about in your README.
I do this whole thing with configure, make even the project is in php
If this was not a config file, and you are sure about the changes you can commit first and then execute pull. Other option is stash which is already told in the error message.
Your changes won't be overwritten. That's what the error message is telling you. The pull failed because git doesn't want to overwrite your changes.
To allow the pull to take place and keep your changes, do git stash before pulling. This will save a copy of your changes and allow you to pull without any issue. Then git stash pop after pulling will restore your changes. Note that you may experience a merge conflict if the changes you are pulling to wp-config.php touch the same part of the file as your local changes.
The other side doesn't have the ignore file in effect yet. Once it's there, you won't have this message. Also it's still tracked. So in addition to changing the .ignore file on both sides, you also need to delete it on both sides and from then on it will not get in the way.
Also take a look at octopress if you are going to be using git as part of your blogging routine.
This is how I'm adding a static response header in my nginx.conf:
location /some-path/ {
add_header X-Some-Static-Header "some static value";
}
Is there a way to add a response header with a dynamic value? This value should be pulled in from a file, or an environment variable, or some similar external place.
I'm trying to add a "X-App-Version" header, which is to be read from a file. When a new version of the web application is deployed, this file will be updated with the new version number. Preferably, nginx should immediately start serving up the new version number, without a restart/reload.
How can this be done?
It doesn't look like there's a way to do this without simply changing the config file when you update the version number. That said, what you're asking for shouldn't be too difficult to automate if you can live with a restart/reload.
If you're using git, (or really any VCS,) you could use commit hooks to trigger a simple shell script to find and replace the line in the config file, run nginx -t -c /etc/nginx/nginx.conf, and restart the server.
I wish there was an existing NGINX module to do what you're asking, so I'm putting that on my todo list, but for most use cases this should probably be a reasonably acceptable hack.