2

I have private repos on GitHub. Most are configured by a config.php. This config is excluded is .gitignore, which works fine until the Eclipse with Egit is used as an IDE.

Eclipse + Egit has a not so wonderful feature of randomly trying to include ignored files (and checked by default) when commits are made. Usually this can be caught and unchecked, but is very hard to find when large changes are pushed because it is a lot of files to read through and consider (3rd Friday of the month: deal with all Notice Errors in log files. Usually handled by the noob person)

So in git, we have a pushed commit, filled with great fixes, legitimate files, and one config.php, that if pushed to the server will destroy the database connection string/file locations/ftp credentials/etc, to the users local test config. Amending the file again won't work, it still changes the file on the server. What ever we do should not result in changes or deletions be pushed to the servers in this file.

The previous procedure was delete the commit, then on the submitting machine:

git reset SOFT HEAD^

and then re-apply the changes in the individual files (excluding config.php), but this last round of fixes... well the commit included 142 files! Nobody has time for that.

Is there a means, via github or git, to remove the changes to or exclude config.php that does not remove or change the file from the target server, user(s) machines, or repository??

Again, the file has been committed, pushed (and was caught in the merge process via conflicts). We do not want this file to be modified or deleted upstream, downstream, ever again. This happens about every 3 months with a new person or haste so we plan on using this procedure frequently.

(all previous questions I have read here do not specifically address this situation, or suggest re-doing each of the 142 files)

Improve this question
6
  • "A pushed commit ... that if pushed to the server"? Has the bad commit been pushed or not, or are you talking about different kinds of pushes? A few paragraphs down you claim that the file has been pushed but caught in a conflict, which would indicate that it actually wasn't pushed. Please clarify the question, and feel free to trim unhelpful rants about Eclipse. Commented Dec 28, 2013 at 18:48
  • The file was pushed to the github repository in a working branch. We are mid-merge with that branch, into branch 'beta'. Once that is done we pull branch beta to the next upstream server. So file file is presently pushed to the repository, and is in limbo pre-pull to the distribution servers. Commented Dec 31, 2013 at 19:23
  • it looks to me like git-stash and recall on each server and development machine may be the only way to avert this file? I'm hoping for someway to blacklist or remove the change. Commented Dec 31, 2013 at 19:27
  • Could you git rm the problem file and then stash, go back, get the old stable version and then re-add and merge the changes? Commented Dec 31, 2013 at 19:33
  • So fix the problem locally (revert the change to config.php or whatever needs to be done), push it to the working branch on Github, and restart the merge to 'beta'? Or complete the merge to 'beta', push a new commit that fixes the problem, then merge from that commit? Commented Dec 31, 2013 at 22:19

2 Answers 2

Reset to default
1
  1. make another copy of the repository
  2. revert that copy to the old version
  3. copy the old version of the file to the original copy of the repository
  4. do what you want with the original repository copy, but it now has the old version of config.php and the new version of everything else.
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

clever, but its still pushing a copy of the file out upstream ?
what do you mean and why is that a problem?
the file, config.php, corrupts all upstream issues that it touches, merges with branches, machines deployed on whether dev, beta, or production, they all get their local configs wiped out as this flows through.
I reversed your process. Copy the repository, revert the original repository, then copy all but config.php from the new back over the original repository. That brought in all the changes, reversed the corrupted file, and was done in minutes. Thank you!
1

The process to "remove" a bad file (config.php) from a good commit by inverting La-comadreja's process. This keeps original repository, good changes, strips out the error, and requires 1 new branch. Repository: Repo1; branch: bad-branch; we will be copying the wanted changes into Good-branch.

1: on Repo1: git checkout bad-branch 2: git log: and find the commit hash to revert to (#88888ABCDEF) 3: git branch Good-branch 88888ABCDEF (or HEAD~1 if one commit) to restart the changes with a clean slate in Good-branch 4: clone repository to Clone1 5: on Clone1: git checkout bad-branch 6: In OS, on Clone1, DELETE bad or unwanted file(s) (config.php, etc) 7: In OS, file copy remaining good files from Clone1/bad-branch, over top of Repo1/Good-branch (IE: copy all files in root directory and paste with over-write) 8: add and commit Repo1/Good-branch (will have all changes minus bad files) 9: delete Repo1/bad-branch just in case. 10: Clone1 can be deleted 11: restart the merge on Good-branch

Time on task: the time to clone the repository and copy the files over. It was 2 minutes for me

Improve this answer

1 Comment

For Eclipse or other tools, "assume unchanged" on certain files helps avert this disaster

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.