Any way to ignore a change to a tracked file when committing/merging?

I've got a problem, or maybe annoyance is more the proper term, that  
I haven't seen solved by any SCM system (at least not to my  
knowledge). Basically, I may make some changes, e.g. to a Makefile or  
somesuch, that I want to ignore when looking at what's changed from  
the repository. The only problem is, the file I've modified is  
already under version control, so .gitignore doesn't do anything.

Now, I can commit it, so it will stop bugging me, but then when I  
push out it will include that change, unless I back it out. This is a  
change that I don't want propagated anywhere else, because it's  
specific to my machine or development sandbox.

Is there any way to do this? I'd really love to use git-commit -a in  
this situation, and I could hack up a script to undo my change, run  
git-commit -a, and reapply the change, but makes me a bit squirmy. If  
I could put something in a .git config file to say "commit 237ab  
should not be propagated under any circumstances", that would be  
fantastic.

-Dave Watson

On Wed, Jun 13, 2007 at 11:47:33AM -0400, David Watson wrote:

I've got a problem, or maybe annoyance is more the proper term, that I 
haven't seen solved by any SCM system (at least not to my knowledge). 
Basically, I may make some changes, e.g. to a Makefile or somesuch, that 
I want to ignore when looking at what's changed from the repository. The 
only problem is, the file I've modified is already under version control, 
so .gitignore doesn't do anything.

Now, I can commit it, so it will stop bugging me, but then when I push 
out it will include that change, unless I back it out. This is a change 
that I don't want propagated anywhere else, because it's specific to my 
machine or development sandbox.

Is there any way to do this? I'd really love to use git-commit -a in this 
situation, and I could hack up a script to undo my change, run git-commit 
-a, and reapply the change, but makes me a bit squirmy. If I could put 
something in a .git config file to say "commit 237ab should not be 
propagated under any circumstances", that would be fantastic.

  please read the thread [ pull into dirty working tree ] that is just
about this, and like errr 2 threads before yours.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

On Wed, 13 Jun 2007, David Watson wrote:

I've got a problem, or maybe annoyance is more the proper term, that I haven't
seen solved by any SCM system (at least not to my knowledge). Basically, I may
make some changes, e.g. to a Makefile or somesuch, that I want to ignore when
looking at what's changed from the repository. The only problem is, the file
I've modified is already under version control, so .gitignore doesn't do
anything.

Now, I can commit it, so it will stop bugging me, but then when I push out it
will include that change, unless I back it out. This is a change that I don't
want propagated anywhere else, because it's specific to my machine or
development sandbox.

Is there any way to do this? I'd really love to use git-commit -a in this
situation, and I could hack up a script to undo my change, run git-commit -a,
and reapply the change, but makes me a bit squirmy. If I could put something
in a .git config file to say "commit 237ab should not be propagated under any
circumstances", that would be fantastic.

Why don't you just use git-commit _without_ -a ?

The whole purpose behind not specifying -a with git-commit is exactly 
for your usage example.


Nicolas

On Wed, 13 Jun 2007, David Watson wrote:

Because git-commit -a is nice to use, especially if I really want to check in
all the files, *except a particular set that is always the same*. Having to
specify the files every time gets old pretty quick.

If I could do this:

$ git-commit -a --exclude=somefile

that would be very useful. Or even, if I could set a file in my .git folder
that would be an exclude list, then I could run something like

$ git-commit -a --use-excludes

I suppose the answer is to create the patch myself.

Well, before that I'd suggest you have a look at the git-add man page, 
especially the -u flag and the core.excludesfile config option.


Nicolas

Because git-commit -a is nice to use, especially if I really want to  
check in all the files, *except a particular set that is always the  
same*. Having to specify the files every time gets old pretty quick.

If I could do this:

$ git-commit -a --exclude=somefile

that would be very useful. Or even, if I could set a file in my .git  
folder that would be an exclude list, then I could run something like

$ git-commit -a --use-excludes

I suppose the answer is to create the patch myself. Seems like this  
would also be a useful feature for git-status, git-ls-files (when  
used with --modified), and probably some others that I haven't  
thought of yet.

-Dave Watson

On Jun 13, 2007, at 1:21 PM, Nicolas Pitre wrote:

On Wed, 13 Jun 2007, David Watson wrote:

quoted

I've got a problem, or maybe annoyance is more the proper term,  
that I haven't
seen solved by any SCM system (at least not to my knowledge).  
Basically, I may
make some changes, e.g. to a Makefile or somesuch, that I want to  
ignore when
looking at what's changed from the repository. The only problem  
is, the file
I've modified is already under version control, so .gitignore  
doesn't do
anything.

Now, I can commit it, so it will stop bugging me, but then when I  
push out it
will include that change, unless I back it out. This is a change  
that I don't
want propagated anywhere else, because it's specific to my machine or
development sandbox.

Is there any way to do this? I'd really love to use git-commit -a  
in this
situation, and I could hack up a script to undo my change, run git- 
commit -a,
and reapply the change, but makes me a bit squirmy. If I could put  
something
in a .git config file to say "commit 237ab should not be  
propagated under any
circumstances", that would be fantastic.

Why don't you just use git-commit _without_ -a ?

The whole purpose behind not specifying -a with git-commit is exactly
for your usage example.


Nicolas

It appears that only applies to untracked files. I am specifically  
interested in ignoring changes to files that are already tracked,  
unless I'm misunderstanding what you're suggesting. I just built the  
most recent git from repo.or.cz/git, and did the following:

* edit the file I want to "ignore"
git-status shows this file as modified

* edit .git/config, set core.excludesfile to myexcludes, containing  
the name of the file I want
* git add -u
* git-status
shows the file I edited as ready to be committed.

Dave Watson

On Jun 13, 2007, at 1:54 PM, Nicolas Pitre wrote:

On Wed, 13 Jun 2007, David Watson wrote:

quoted

Because git-commit -a is nice to use, especially if I really want  
to check in
all the files, *except a particular set that is always the same*.  
Having to
specify the files every time gets old pretty quick.

If I could do this:

$ git-commit -a --exclude=somefile

that would be very useful. Or even, if I could set a file in  
my .git folder
that would be an exclude list, then I could run something like

$ git-commit -a --use-excludes

I suppose the answer is to create the patch myself.

Well, before that I'd suggest you have a look at the git-add man page,
especially the -u flag and the core.excludesfile config option.


Nicolas

onsdag 13 juni 2007 skrev David Watson:

I've got a problem, or maybe annoyance is more the proper term, that  
I haven't seen solved by any SCM system (at least not to my  
knowledge). Basically, I may make some changes, e.g. to a Makefile or  
somesuch, that I want to ignore when looking at what's changed from  
the repository. The only problem is, the file I've modified is  
already under version control, so .gitignore doesn't do anything.

Now, I can commit it, so it will stop bugging me, but then when I  
push out it will include that change, unless I back it out. This is a  
change that I don't want propagated anywhere else, because it's  
specific to my machine or development sandbox.

Is there any way to do this? I'd really love to use git-commit -a in  
this situation, and I could hack up a script to undo my change, run  
git-commit -a, and reapply the change, but makes me a bit squirmy. If  
I could put something in a .git config file to say "commit 237ab  
should not be propagated under any circumstances", that would be  
fantastic.

git update-index --assume-unchanged <path>

Then commit -a like you are used to.

-- robin

On Wed, 13 Jun 2007, David Watson wrote:

It appears that only applies to untracked files. I am specifically interested
in ignoring changes to files that are already tracked, unless I'm
misunderstanding what you're suggesting. I just built the most recent git from
repo.or.cz/git, and did the following:

* edit the file I want to "ignore"
git-status shows this file as modified

* edit .git/config, set core.excludesfile to myexcludes, containing the name
of the file I want
* git add -u
* git-status
shows the file I edited as ready to be committed.

I suppose that the behavior of git-add could be modified to honnor the 
exclude pattern even for already tracked files.  Such change would make 
sense to me.


Nicolas

On Wednesday 2007, June 13, David Watson wrote:

I've got a problem, or maybe annoyance is more the proper term, that
I haven't seen solved by any SCM system (at least not to my
knowledge). Basically, I may make some changes, e.g. to a Makefile or
somesuch, that I want to ignore when looking at what's changed from

So you want to tell git to track a file and then have it not track 
changes to that file?  Sounds crazy to me.  Don't put files in the 
repository that you don't want tracking.

What you want is an out-of-tree file for that sort of thing.  Why can't 
you just do

#!/usr/bin/make
-include Makefile.local

Rather than messing around with not tracking tracked files?

git does exactly that in it's own build process with a config.mak file, 
which lets you specify, say, an install directory that is obviously 
only valid for you.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com