Ignoring local changes

Ignoring local changes

[Pazu]

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

Re: Ignoring local changes

[Andreas Ericsson]

Pazu wrote:
> 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.
> 

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.

> 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?
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

Re: Ignoring local changes

[Pazu]

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

> 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.

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

> This feels like a bug to me.

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.

Re: Ignoring local changes

[Rogan Dawes]

Pazu wrote:
> 2006/12/14, Andreas Ericsson <ae@op5.se>:
> 
>> 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.
> 
> 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
> 
>> This feels like a bug to me.
> 
> 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

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.

Re: Ignoring local changes

[Pazu]

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

> 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.

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?

Re: Ignoring local changes

[Pazu]

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

> I know, could remove them only from my local branch, and never push the
> commit that removed the files…

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

Re: Ignoring local changes

[Johannes Schindelin]

Hi,

On Thu, 14 Dec 2006, Pazu wrote:

> 2006/12/14, Rogan Dawes <discard@dawes.za.net>:
> 
> > 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.
> 
> 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?

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