Re: Ignoring local changes

Is there any way to make git completely ignore changes to certain local files? I know about .gitignore, but that doesn't work when the files I want to ignore were already added to the repository.

A little more context should help you understand my need. I'm currently tracking a big subversion repository using git-svn; I do all my develop on local git branches, and later use git-svn dcommit to push these changes to the svn repository.

There are some files in the svn repository (and by extension, on my local mirrored repository) that are almost always locally modified (eclipse/IDEA project files or generated artifacts that someone else added to svn), but I almost never want to commit then. This is a hassle in several situations:

1) git-status always show these files as modified, polluting the output and
making it harder for me to pinpoint the "real" changes.
2) git-rebase refuses to run, since the working copy will always be dirty*
3) since git-svn dcommit uses git-rebase, sometimes it fails for the same reason.

So, is there any way to make git look the other way regarding these files?

* I usually get around this making a local commit with the local modifications,
rebasing, and the using git-reset to revert the last commit.

-- Pazu

Pazu wrote:

Yes it does. Just add the file to .gitignore and it won't be noticed anymore.

Correction: I just tested this, and while git-add won't touch the file, 
git-update-index will, and git-status still shows it as modified.

This feels like a bug to me.

man git-ls-files, search for .git/info/exclude and see if that works for you.

On a side-note, it would be neat if it was possible to set --exclude-per-directory as a config option. It would save an awful lot of hassle for imported repositories. Even more so if git-{cvs,svn,p4}import and the lot set it up automagically.

2006/12/14, Andreas Ericsson <ae@op5.se>:

Yes, and that's exactly my problems. There are a number of modified/removed files in my working copy that were previously added to the repository, and git-status shows them as modified/removed, even when they're listed in .gitignore or .git/info/exclude

Dunno, sounds like this is by design. I acknowledge that my situation is unusual, and most often, you'll want to always track a file once it's been added to the repository.

Pazu wrote:

Why not remove it from the repo, then set .gitignore?

If it is generated code, or compiled code, it probably shouldn't be in the repo in the first place . . . Simply correct that mistake, and you are good to go.

2006/12/14, Rogan Dawes <discard@dawes.za.net>:

Basically, because I don't want to mess with the upstream. I know, I can remove them only from my local branch, and never push the commit that removed the files, and that's what I'll probably do if there's no other way -- but it would be best if I could just ignore the files. It doesn't sound unreasonable, does it?

Pazu <pazu <at> pazu.com.br> writes:

And that makes me think about yet another nice feature: configure git[-svn] to "block" a commit, meaning that a blocked commit would never be pushed out when doing a git push or git-svn dcommit.

-- Pazu

Hi,

On Thu, 14 Dec 2006, Pazu wrote:

It is not unreasonable. But I could not find an easy way to do it with git. It should be easy to hack it into it, though.

Ciao, Dscho