threads / discuss / 8593

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

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

## tl;dr

10 messages between Jun 13, 2007 and Jun 13, 2007.

replies: 9people: 6as markdown or json

David Watson· Jun 13, 2007, 15:47 UTC · lore

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

Pierre Habouzit· Jun 13, 2007, 16:33 UTC · re: David Watson · lore

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

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

Show 17 quoted lines

> 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

Nicolas Pitre· Jun 13, 2007, 17:21 UTC · re: David Watson · lore

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

On Wed, 13 Jun 2007, David Watson wrote:

Show 17 quoted lines

> 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

David Watson· Jun 13, 2007, 17:41 UTC · re: Nicolas Pitre · lore

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

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:

Show 38 quoted lines

> 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

Nicolas Pitre· Jun 13, 2007, 17:54 UTC · re: David Watson · lore

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

On Wed, 13 Jun 2007, David Watson wrote:

Show 14 quoted lines

> 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

David Watson· Jun 13, 2007, 18:09 UTC · re: Nicolas Pitre · lore

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

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:

Show 25 quoted lines

> 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

Nicolas Pitre· Jun 13, 2007, 18:19 UTC · re: David Watson · lore

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

On Wed, 13 Jun 2007, David Watson wrote:

Show 13 quoted lines

> 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

Robin Rosenberg· Jun 13, 2007, 18:30 UTC · re: David Watson · lore

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

onsdag 13 juni 2007 skrev David Watson:

Show 18 quoted lines

> 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

Andy Parkins· Jun 13, 2007, 19:34 UTC · re: David Watson · lore

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

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

Junio C Hamano· Jun 13, 2007, 19:57 UTC · re: Andy Parkins · lore

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

Andy Parkins <andyparkins@gmail.com> writes:

Show 9 quoted lines

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

Actually, that is a sign that either the upstream project is broken, and/or the user's workflow is broken.

Taking an example closer to home, if we tell tell users "in config.mk file you can suit your local needs" and at the same time add config.mk to the official repository, that would be crazy. The changes to that file is _supposed_ to be local and the other side will never be interested in getting updates to that file. So if David is dealing with such a situation, then the problem is in the project organization.

On the other hand, it is usual to see a comment in the Makefile that says "# No user tweakable part below this line", with expectations that users will muck with make variable definitions in the earlier parts of the Makefile to suit the local filesystem layout and such.

The changes users will make to such a file fall into one of two categories:

 (1) Local configuration changes to adjust to the user's
     particular installation.

 (2) Fixes, improvements and enhancements to the generic part
     ("below that line").

Other people, especially the "upstream" people, are never interested in ever seeing patches of the former kind, while the latter are of general use and you would want to feed themback.

You would need to separete out these two kinds at SOME stage when you need to make changes of both kinds. You can do that at patch submission time, cleaning up the series, if you are feeding the changes via patches.

If you are communicating with the other side via pull/push, then you would need to have two histories that cleanly separates the two. Probably a good workflow is:

 - The tracking branch remotes/origin/master; this holds what is
   'pristine';
   
 - Keep 'master' branch for only the changes for general
   consumption.

 - Have a separate 'local' branch, that is forked from 'master'
   branch of yours.  Local configuration changes will go to this
   branch, never to 'master'.

You would never publish 'local' as it contains the local configuration changes that are of no interest to others, but the changes you may want to give back to outside will be readily available in 'master'.

If I _were_ doing this, I would further use a topic branch that forked from pristine to hold only the local changes, and use 'local' only as an integration branch between that local configuration topic and 'master' (i.e. no commits will be made to 'local' directly -- everything will come from either separate topics or 'master').