On 02/19/14 12:56, Thomas Ferris Nicolaisen wrote:

On Wednesday, February 19, 2014 12:31:26 PM UTC+1, Gunnar Strand wrote:

    Hi Oleg,

    There are probably other better solutions, but one way would be to
    add a .gitignore file listing the particular file you do not want
    tracked, and add the .gitignore itself file too.

    http://git-scm.com/docs/gitignore <http://git-scm.com/docs/gitignore>

Since the file is already tracked in this case, doing a normal ignore
will not help.

Right, I stand corrected. It even appears to be gitignore 101.

After some researching using the normal tools, your suggestion of using assumed-unchanged seems appropriate. I find this an interesting problem, but I have been unable to find any trivial solution.

As an alternative, I added the following to a pre-commit hook:

git checkout ignoreme
git reset HEAD ignoreme

This would also solve the problem, but is less elegant than "--assume-unchanged". However, a pull after a commit would result in the ignored
file to be updated with the upstream changes.

But the above test also revealed what I believe is a bug in git. After the pre-commit is executed with "git reset", the "ignoreme" file is still listed as being committed:

# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
# modified:   ignoreme

And adding a commit message results in an empty commit:

ign2$ git --no-pager diff HEAD^ HEAD

I think git should reevaluate the state after the pre-commit hook has been executed, and not create an empty commit unless "--allow-empty" is given to commit. I've submitted this on the bug list.


You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to