The best practice we've settled around is that developers don't connect Eclipse to a packaging or patch org. Instead, all coding is done in the developer's own DE org, committed to a branch in GitHub, and then deployed to the patch/packaging org by Jenkins (or any other automation tool of your choice).
The packaging and patch orgs are only changed by an automated process which moves code from the repository to the org.
If you have work done in a patch org you need to pull into git, you might be best to just use Ant to retrieve it rather than using Force IDE. Here's an example of the target we use to retrieve packaged metadata:
https://github.com/SalesforceFoundation/Cumulus/blob/feature/721-allocations/build.xml#L402
That target calls this macro:
https://github.com/SalesforceFoundation/Cumulus/blob/feature/721-allocations/lib/ant-salesforce.xml#L192
Using the macro, you can simply do something like:
ant -propertyfile PATH/TO/CREDENTIALS/FILE retrievePackagedToSrc
That will pull all the metadata from the package in the target org into your local directory. You can then use whatever Git tool you want to use to commit those changes to a branch of your repository.
I can't stress enough how important it is to invest in build scripts which can deploy your managed package code from the repository into a packaging org so you can automate that process. If the only tool you have to deploy to packaging/patch orgs is Eclipse, you're restricting what can be automated after your process. The purpose of automation is not only to make your life easier but also to ensure that nothing goes into your packaging/patch orgs before it's been tested elsewhere.
