Phil,
Thank you for your response. I do see the dilemma, but having
no possible "unmodified" state is extremely inconvenient and,
as shown, breaks basic git operations.
I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as "unmodified". It just
doesn't make sense to me that files are considered modified
immediately after checkout.
Any thoughts as to why this would not work?
---John
On 10/4/12 9:19 AM, Phil Hord wrote:
On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <jjw@xxxxxxxxxxxxxx> wrote:
I just ran into a problem that I'm pretty sure is a bug in git. Just read
and run this (fairly trivial) shell script to replicate.
When you added "* text=auto" in the .gitattributes file, you changed
what git considers to be the checked-in file content state for
test.txt. The file contents in your working directory do not match
what git expects to check in. Therefore, the file appears to be
different. If you commit the file "changes" the problem goes away.
This is more of a workaround than an a satisfying explanation. If you
then checkout the original HEAD commit (but with .gitattributes
present) you will see the problem appear again. But in a sense,
adding .gitattributes this way is an act of foot-shooting. The best
way forward may be to normalize your repository by removing all CR's
from files in history. If you do not have this freedom, your best bet
may be to normalize the repo in the current commit and move on.
Others with more intimate insight into the CRLF journey in git's past
may have better advice.
Phil
--
Great support for great users! Please visit http://emsoftware.com/support/ for our support policies, instructions and FAQs.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html