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
ign2$
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.
BR
Gunnar
--
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.
