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

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

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

-Dave Watson

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

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Nicolas Pitre]

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

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

[David Watson]

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

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

[Nicolas Pitre]

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

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

[David Watson]

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

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

[Nicolas Pitre]

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

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

[Robin Rosenberg]

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

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

[Andy Parkins]

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

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

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