provide simple option to set unix style on windows platform(Git Bash)

[xheke]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

** insert your machine's response here **

git version 2.19.2.windows.1
cpu: x86_64
built from commit: 26dcaa1
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

** insert your machine's response here **

Microsoft Windows [Version 10.0.16299.726]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

** insert your machine's response here **

$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

** insert your response here **
GIT bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

** insert your commands here **

git apply ../diff/abc.diff

• What did you expect to occur after running these commands?

** insert here **

We want prevent commit code files with DOS format to repository.

Therefore, we enable client standard/default pre-commit hook on both Linux side and Windows side.

The hook works fine on Linux side as expected, but not works on Windows side.

We also observed that when we try to import diff with new DOS format files on the Linux side, GIT will report some whitespace warnings and this may lead commit failure with pre-commit hook impact. However, nothing happened on windows side if we do the same commands, and the commit will success even we enable the same pre-commit hook on Windows side.

We hope team can work with same style, no matter he/she work on Linux side or Windows side.

The behavior is different between Windows side and Linux side currently. In addition, we try to set core.autocrlf and core.safecrlf on Windows side, anyway, it does not prevent commit. Therefore, we hope if there have simple option to set like Linux-style on GIT bash (Windows Side) to simulate Linux environment (perhaps just for file format checking is enough) on Windows side.

• What actually happened instead?

** insert here **
no whitespace warnings report

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

** insert URL here **

[dscho]

find out all ^M errors caused by CRLF (DOS format)

Could you elaborate?

pre-commit hook can work on linux to prevent ^M commited as expected

What pre-commit hook?

It would be good to come up with a Minimal, Complete & Verifiable Example to drive this ticket forward.

[xheke]

rewrite the description, please comment if anything is still not clear. Thanks.

[dscho]

Therefore, we enable client standard/default pre-commit hook on both Linux side and Windows side.

The hook works fine on Linux side as expected, but not works on Windows side.

Without seeing that hook, there is little anybody else can do (except for conjecturing wild guesses).

In any case, it might be as benign as a lack of the appropriate eol attributes in your .gitattributes. See https://www.edwardthomson.com/blog/git_for_windows_line_endings.html for details.

And for the record, your edits did not provide any example, let alone a minimal, complete & verifiable one. So the ball is squarely in your court, still.

[xheke]

Thanks dscho very much.

I think “* text=auto” is the solution that what we are looking for. I will try to suggest our administrator to set this in the repository.

But personally, I still suggest GIT-bash can provide unix-style option for local git configuration on windows system. Since autocrlf is not suggested for cross-platform team work.

For this issue reproduction, we can follow below steps:
1, change .git\hooks\pre-commit.sample to pre-commit
2, add one DOS-format file
3, make the diff for this new add DOS file
4, git reset
5, apply the diff
Case for linux platform: we can see whitespace error, and commit will failed prevented by pre-commit hook.
Case for windows platform: no whitespace error, and commit will success, pre-commit hook can not prevent commit at all.

[dscho]

For this issue reproduction, we can follow below steps:
1, change .git\hooks\pre-commit.sample to pre-commit
2, add one DOS-format file
3, make the diff for this new add DOS file
4, git reset
5, apply the diff
Case for linux platform: we can see whitespace error, and commit will failed prevented by pre-commit hook.
Case for windows platform: no whitespace error, and commit will success, pre-commit hook can not prevent commit at all.

In these steps, I do not see any git commit command, so I am puzzled how the pre-commit hook plays any role here.

Could you please turn this MCVE into a real script?

[xheke]

Hi dscho,

Please following below steps and try to reproduce it on Windows platform:

1, change .git\hooks\pre-commit.sample to pre-commit
2, git reset --hard
3, add one DOS-format file, such as dos.txt
4, git add -A
5, git diff --cached > ../mydiff/dos.diff
6, git reset --hard
7, git apply ../mydiff/dos.diff
8, git add -A
9, git commit

Here will no warning in Step 7, and will success on step 9.
But if we do the step 6&7 just with same diff on the Linux platform, here will get warning and lead step 9 failure.

Thanks,
Ke

[dscho]

@xheke so when I try this, I see what you are seeing. But on Windows, the committed file is not CR/LF. It is in the worktree, but not in the Git index (verify for yourself, using git ls-files --eol).

To get the same behavior on Windows as on Linux, you simply have to set core.autocrlf to false on Windows.

You can even do that by choosing the option "Checkout as-is, commit as-is" in Git for Windows' installer.

Does that clarify why you see what you see?

[xheke]

Hi dscho,
As I said, it doesn't work.
Sure, we can set core.autocrlf to false, but the problem is the new guys or some team players always forget to check the new files created is UNIX-style or Windows-style(rely on their edit tools), and when they commit their work, the pre-commit hook doesn’t work fine as we see.

That why we need one option to set UNIX-style or Windows-style for git base environment, we hope when we set UNIX-style option for git bash, the pre-commit hook (or something else, perhaps is diff) can auto detect the DOS format files and prevent commit as on UNIX platform behavior.

Thanks for your help.
Ke

[dscho]

we need one option to set UNIX-style or Windows-style for git base environment

Yes, and we do have that. I even pointed it out to you:

You can even do that by choosing the option "Checkout as-is, commit as-is" in Git for Windows' installer.

This is the option that you asked for.

Having said that, I think you'd be a lot better served by following the excellent advice in https://www.edwardthomson.com/blog/git_for_windows_line_endings.html. Since you want Unix line endings (LF-only, to be precise) in all your files, just add a file .gitattributes (unless it exists already) and declare * eol=lf.

In short: there are ways in Git to get what you want.

[xheke]

”You can even do that by choosing the option "Checkout as-is, commit as-is" in Git for Windows' installer.”

-- this option only work for existed files but no impact for new files.

“Having said that, I think you'd be a lot better served by following the excellent advice in https://www.edwardthomson.com/blog/git_for_windows_line_endings.html. Since you want Unix line endings (LF-only, to be precise) in all your files, just add a file .gitattributes (unless it exists already) and declare * eol=lf.

In short: there are ways in Git to get what you want.”

-- agree，it is right way. But I am not the GIT administrators in our product/project. I already ask them to change the setting. but there are long process in our company，till to now，no response from them.

so, if we can do something from local, that may helpful.

[dscho]

@xheke you do not change .gitattributes by asking Git administrators, but by committing the file .gitattributes. You can open a Pull Request for this, for example.

In any case, it has become clear that this is not a bug in Git for Windows, so I'll close this ticket.

[xheke]

Yes, it is not bug, but one suggestion.

thanks.

[PhilipOakley]

Are we not accidentally talking across each other here.

Hooks are not stored in the repo object store, so (IUC) are not subject to the various attribute settings. The various bits of advice about setting attributes, while useful, are closing the stable door after the horse has bolted (aren't users annoying;-). The hook is meant to be a poka yoke test, and it's failing...

As @xheke says, "the pre-commit hook doesn’t work fine", and it is the (reading of) pre-commit hook that in some way needs fixing, so that if it has CRLF endings (on Windows), then it should work the same as if it had only LF endings on Linux.

Now I see that this problem could be:

1. an upstream git problem (punt patches to them;-)
2. a local Git-for-Windows patch in the thicket (but..)

For point 2, I'd still see that as needing a contributor (@xheke and colleagues) provided PR. However it is more important to agree what the problem actually is, and avoid the XY-Problem aspect.

[dscho]

@PhilipOakley the pre-commit hook contains code to prevent CR/LFs from being committed. The problem pointed out was that this hook does not trigger on Windows. The reason why it does not trigger, however, is that there are no CR/LFs to be committed when core.autocrlf=true.

And from there, the discussion evolved to cover the aspect of having a different autocrlf setting on different platforms.

So I still think that we resolved this conundrum to @xheke's satisfaction.

[xheke]

Thanks @PhilipOakley, I think you got my points exactly.

@dscho, I have no right to change .gitattributes since it is controlled by the administrators.

For point 2 listed by @PhilipOakley, whatever core.autocrlf set to true or false, include "Checkout as-is, commit as-is" option, we still have no way to avoid colleagues continue to commit more and more format errors to DB during this period.

That real let me very upset ... ...

[xheke]

@dscho , please consider below scenarios:
( we assume: core.autocrlf set to false with "Checkout as-is, commit as-is" option)

scenario 1:
1, new files as DOS format are created on windows
2, commit these files to DB on windows ( will success)

scenario 2:
1, checkout DOS format files from DB
2, edit then commit these files to DB on windows ( will success)

For these two scenarios, the errors will be increased day after day.
(In our agile project, 20 team members, the errors from hundreds increased to thousands in short time)

if we have unix-style options, for these two scenarios, the commit will failed, that will force or remind colleagues to check file's format. In this way, we can avoid to increase errors and decrease already existed errors in DB day after day.

BTW, the administrators may not change .gitattributes for some other reasons from their view, I guess in some complex conditions.

[dscho]

BTW, the administrators may not change .gitattributes for some other reasons from their view, I guess in some complex conditions.

Well, you asked how to fix it, you got the proper solution, and now you tell us that you need another fix because somebody refuses to apply the necessary changes.

I have no idea how I can help, then!

[xheke]

@dscho, this is just suggestion, that may help others with some conditions like me in the future.

provide simple option to set unix style on windows platform(Git Bash) #1959

I don't know why our administrators still not change this attributes, it is just my guess, i don't know the real reason. but it is another problem not related to this suggestion.

[PhilipOakley]

On 02/03/2019 01:59, xheke wrote: Thanks @PhilipOakley <https://github.com/PhilipOakley>, I think you got my points exactly. @dscho <https://github.com/dscho>, I have no right to change .gitattributes since it is controlled by the administrators.

@xhehe, could you describe how your local repository is setup and why the administrators have so much control? I am guessing that the local repository is on a drive letter that is actually a network share allocated to you, but hosted on a central server (rather than your hard/SSD drive). And that the .gitattributesfile has been locked as a read only, administrator access file. Are you able to share the content of that file (with sensitive aspects removed/redacted). Also, what method is used for re-integrating individual changes into the upstream master? Which workflow is used - see https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows - are you (a) Centralized Workflow (b) Integration-Manager Workflow (c) Dictator and Lieutenants Workflow, or (d) special local variants? Within the flows (especially b&c) there are two types of upward flow: (1) patches, (2) Pull Requests (split `git` and GitHub styles)

For point 2 listed by @PhilipOakley <https://github.com/PhilipOakley>, whatever core.autocrlf set to true or false, we have no way to avoid colleagues continue to commit more and more format errors to DB during this period.

Are you able to personally visit the colleagues who have the 'problem' to help and advise them? If you are able to set your _personal_ core.autocrlf [1], then visiting colleagues and getting them to change their _personal_ setting may be the best way to at least remove the most significant problems.

That real let me very upset ... ...

I would agree that if the administrators have a poor default setup (and not user training) then it can be an issue. Choosing the right defaults can be hard. However Git is a _distributed_ system so everyone gets to have their own control, which is confusing for managers in a command and control style system. Philip [1] if you can change your local core.autocrlf then you do have hope...

[dscho]

I still don't get why setting core.autocrlf (probably to "input") isn't accepted as answer.

[PhilipOakley]

I still don't get why setting core.autocrlf (probably to "input") isn't accepted as answer.

I expect that the confusion is because it is not @xheke that needs to make the change. It is the 'colleagues' (wherever they may be) that need to be made to change their settings.

And that would need some bigger management action that isn't in @xheke's gift, leaving @xheke frustrated that there is almost nothing 'they' can do beyond whinging to indifferent management/administrators.

Plus, reading between the lines, @xheke then has to fix the issue created by those 'bad' commits.

To summarise, it is a right answer, but does not distribute well (or at all) in @xheke's environment, hence the XY-problem aspects!

I think they may need an Automated Integration Manager Workflow, where instead of a race to commit first (Centralised flow), they send a PR, which is then auto checked, and if passing, can be committed to the golden repo, but again, it needs management to do something (and when does that happen ;-) It's a people / social problem, not a Git [technology] problem!

[dscho]

To summarise, it is a right answer,

No, the right answer is changing .gitattributes, but it is rejected with emphasis.

[xheke]

@PhilipOakley, thanks for your help.

I can not get the whole picture for our git flow. But let me try to describe our work flow:

Our team work on the branch for the feature of the product, at the same time, other teams may work on the other branch together.

Feature Teams, include administrators team, may come from the whole world, we don't know each other but communicate by email or issue track system. that is the brief background information.

In general, we follow below steps to work:
1, git clone and copy hooks (defined by administrator teams, otherwise, we cannot push our change) from remote repository in local server ( colleagues may like Linux platform or windows platform, determined by themselves)
2, checkout our work branch
3, commit our work ( may need rebase and merge before commit)
4, push change to the remote repository with hooks.
5, waiting remote Jenkins checking, if check failed, the change will roll-out in remote repository absolutely.

From page provided by @dscho, I saw .gitattributes should be configured in the repository but not in the local Git configuration.

The difference between these two options is subtle, but critical: the .gitattributes is set in the repository, so its shared with everybody. But core.autocrlf is set in the local Git configuration. That means that everybody has to remember to set it, and set it identically.

I send mail to our administrators team and provide three suggestions:

1. follow page's comments provided by @dscho, to change .gitattributes (thanks @dscho )
2. enable pre-commit hook ( only commit-msg hook enabled by administrators currently, but we can enable pre-commit manually in local)
3. add one check to prevent 'bad' commit with errors in remote Jenkins

Seems the suggestions are still under discussion in administrator team during this time.
The errors has been consistent growth at the same time.

I agree with you, It's a people / social problem, not a Git [technology] problem!

I have no idea how to handle this problem, what I can do is ensure my work is good.

I talked to my colleagues, most of them may have confusion how to set core.autocrlf , from my view, it should be set to "input", is that right?

Anyway, I am so upset for current environment :(

Hope pre-commit hook is work both for UNIX platform and Windows platform in the future ... ..

Hope our administrators take action ASAP :)

[PhilipOakley]

Hi @xheke

I think the discussion should be taken to the Git-users group list (https://groups.google.com/forum/#!forum/git-users), to avoid cluttering the bug tracker.

I talked to my colleagues, most of them may have confusion how to set core.autocrlf , from my view, it should be set to "input", is that right?

That will depend....

1. You need to identify the specific file types that create the errors/conflicts, and
2. decide for that file type what the right line ending format is.
3. Then you can tell the .gitattributes file what to do with those types of files so that the Windows and Linux users both produce correct ending in the repository, and local line endings when checked out into their working directories.
4. You will also need to make sure that the updated .gitattributes file settings get into the upstream repo and then back down to the other teams so that it is also within their feature branches!

The pre-commit hook is a red herring as it is also a local (personal) setting, with the same roll out issues.

It is only the upstream server that could do checking before accepting a push from someone (who may have made the mistake). That would be a pre-receive hook (and needs to be done by the admin of that server)

[xheke]

Many thanks @PhilipOakley for your very kindly help !

[xheke]

The comment from management team:

We had an internal discussion about this ticket. From project side, you should be able to implement yourself. The file .gitattributes should be added (committed) to each directory/branch where you need to eliminate Windows EOLs, but this will not be enough. It will start to eliminate EOLs from the moment you activate .gitattributes, but for the existing files you will need to convert them to be sure there is no Windows EOLs inside of them (around 1625 files). If you don't do this, you will generate many conflicts. Only after this project, you can create a pre-check verification job which will enforce Unix style EOLs.

Pre-commit hook in local repositories is hard to manage on the central level. Unlike 'check' on the Gerrit side (or pre-check jenkins jobs) you have no way to enforce that a user has a pre-commit hook enabled in their clone and that they use the latest version of it. So this is a questionable approach but of course may help them at least to minimize the number of pre-check jenkins job fails.
To enable it a user needs to install 'pre-commit' file into their .git/hooks folder in the local clone.

Existing pre-commit.sample does not check EOL styles.
You should write by yourself the pre-commit hook to eliminate Windows EOLs and introduce a process in which ever project member can install it in their cloned repositories themselves.

Now, the question of 1:'doing it only for future files' vs. 2:'normalize existing files first' ? It is a matter of choice. Both are doable, both have pros and cons.
a) We are recommending you the option 2, it's cleaner and you can see the result early -- pre-check job will fail sporadically after that.
b) Option 1 has no initial cost, but when users prepare new commits they will need to normalize every file they touch in their change. 'text=auto' will not fix the EOL style; they will need to remember to convert the file themselves.
If they don't and they don't have local pre-commit hook installed --then pre-check job will fail.

From our support point of view, t{color:#000000}he cleaning and set-up of environment of developers own clones should be done locally by projects. Us as support, we can offer guidance (E.g. suggested steps how to handle windows style EOLs), providing configuration (E.g. Hooks) . The scale of project own clones requires that developers will maintained locally - having it done centrally (e.g. by us as support) introduces risk of introducing another bottlenecks. {color}

My answer:

It’s not my problem but it is team work problem. We know how to avoid commit Windows EOLs by training or communicate each other. In fact, this is the XY-Problem aspect. People may always forget check their files before commit, that what we see in the current project.

So, for option 3, add one job in the Jenkins to refuse commit any change with errors in remote repository for the specific project, that may best way to avoid the problem like us met in the future.

I think there are two levels to manage this problem( diff errors check):
1, on central level, via Jenkins checking
2, on local level. via pre-commit hook, (suggest provide "UNIX style option" to keep same behavior both for UNIX platform and windows platform)

Anyway, it is suggestion.

Best Wish,
Ke

[PhilipOakley]

an aside: could you (@xheke ) clarify/annotate who the various "we/you/your/they" statements refer to. This is so that there is no confusion between different groups (both within the corporate structure and the open source git teams) as to where fingers are being 'pointed' or 'suggestions' being made, as to who should (or should not) do which bit of work.

At the moment it looks like you are "between a rock and a hard place" (where ownership and authority have been separated).

Also consider (via https://githooks.com/), e.g. * pre-receive: Enforce project coding standards. ...

If I read correctly, it would be the support group that would install such a hook (on the teams project server), but you would code it and test it first, by locally push/pulling to a second repo acting as a server via the file:// transport such that the hooks get triggered on your local machine. If you can demonstrate the hook, then you can take them (support group) up on their promised offer of support...

[xheke]

@PhilipOakley, thanks for you kindly help first :)

I’m not quite understand you first question, seems there are two groups, the corporate structure and the open source git teams.

Yes, in our company, the ownership and authority have been separated.

We have coding standards or coding rules, but unfortunately, for this problem, seems the administrator or management team think it should be solved by develop team, however, the develop team think it should be solved by management team.

In personally, from my view, it should be handled by management team, that because they are last goalkeeper.

The management team suggest us (develop team) to modify the standard hook locally, it is not the good idea, at least it is not the general solution. Absolutely, they observed there are around 1625 files in the repository not correctly saved in the past months or years. And I guess they also are aware the hook can not work on the window platform, so they suggest us to modify the hook to check EOL by ourselves. But it is not good idea from my thought, the hook should not be changed by them or us. It should be kept original and simple.

That is why I said, provide UNIX style option in “git bash”, to take the same behavior of the hook is the suggestion.

It is not my responsibility to avoid this problem between people and people, team and team, but I hope if we have some way to solve it in the future.

[PhilipOakley]

hi @xheke

I’m not quite understand you first question, seems there are two groups, the corporate structure and the open source git teams.

Just to clarify, and answer your question, I had the divisions more finely divided:

1. Your corporate support team
2. your project team
3. you (@xheke) (lone worker toiling against the trials and tribulations of 1 & 2 😩 )
4. The upstream Linux Git 'team' (who tolerate those fools on Windows 😄)
5. the Git-for-Windows (g-f-w) 'team' (wearily working through all the differences in OS abstractions and Windows user expectations)
6. dscho, maintainer g-f-w, who does the majority of the heavy lifting, without whom ...
7. the likes of me @PhilipOakley ...

Back in #1959 (comment) you (3) quoted a response from your (1) support group which had a "you" in it - "you should be able to implement yourself", it was there that the potential 'who is you?' starts. I think they(1) are pointing at you(3), but really need to point at you(2), etc. etc. From the distance of being No 7 in the list it is easy to misunderstand, while for you at No3 there does not appear to be any ambiguity - which was why I asked initially (that's just to clarify, it's not an issue).

modify the standard hook locally

Which type of hook is this hook?

I guess they also are aware the hook can not work on the window platform

Do you mean that the type of hook above does not execute at all on Windows?
or that the script you(3,2)/they(1) have created, when executed on Windows, does not do what they(1)/you(2) expect/hope? (but that you(3) realise is useless;-)

behavior of the hook

As noted in (5), the 'differences in OS abstractions and Windows user expectations' means that dscho's much earlier comment is still generally true. I doubt that there is an easy solution.

It is not my responsibility..

You (your(2) project) will need a 'flag day' where all the line ending errors are corrected, and a server side(1) script for your project that simply refuses to accept new commits that users attempt to push to the 'blessed' repository that contain such errors. You(3) can write such a script.

My apologies if I(7) have gone on too much.

[dscho]

the hook can not work on the window platform

That statement is incorrect, as I pointed out a couple times already. The hook does work correctly. It just does not detect any problem because core.autocrlf = true already prevents it. I'll not say this again.

[dscho]

That is why I said, provide UNIX style option in “git bash”, to take the same behavior of the hook is the suggestion.

It is still unclear what you mean, but I get more and more the impression that you want me to change the default from core.autocrlf = true to core.autocrlf = false, which would not only not solve your problem (in fact, it should prevent it at least for the Windows developer part of your team!), but it would break the promise we set over ten years ago. So: if that is what you want, then my answer is "absolutely not!".

[PhilipOakley]

@xheke Are you able to post your current and project .gitattributes, git config and that standard hook, or at least the relevant parts? As has been noted a few times, this (at project scale) is a social / management issue. Identify the starting point, and a desired end point , and plan a route...

[xheke]

That statement is incorrect, as I pointed out a couple times already. The hook does work correctly. It just does not detect any problem because core.autocrlf = true already prevents it. I'll not say this again.

@dscho, I got your message this time. I redo the test with core.autocrlf = false again, this time, I got I want, you are right, if core.autocrlf = false, the hook can work fine just as in UNIX platform.
The popular saying, the import thing should be said three times :)
I'm so sorry, I forget why I got the impression the core.autocrlf = false is not work in the early.

Perhaps, from my view, core.autocrlf = false is almost like unix-style(in our cases), but something look like a little strange.

autocrlf like behavior/action, unix/windows style is like a mode.

It is still unclear what you mean, but I get more and more the impression that you want me to change the default from core.autocrlf = true to core.autocrlf = false, which would not only not solve your problem (in fact, it should prevent it at least for the Windows developer part of your team!), but it would break the promise we set over ten years ago. So: if that is what you want, then my answer is "absolutely not!".

No, it is not my want. I just want to find out the solution, you give me two useful suggestions. One for remote, one for local, it is really help me, and it is enough. there are some misunderstanding for the local solution, it is my fault. Sorry for that.

For this issue, my suggestion is, can we consider use:

unix-style
windows-style

replace:

core.autocrlf true
core.autocrlf false
core.autocrlf input

[xheke]

@xheke Are you able to post your current and project .gitattributes, git config and that standard hook, or at least the relevant parts? As has been noted a few times, this (at project scale) is a social / management issue. Identify the starting point, and a desired end point , and plan a route...

@PhilipOakley, thank you so much!

Without your help, I can not go there.

I can not find any .gitattributes file in local directory, I also afraid if I change .gitattributes and push it, that may impact something else. :(
(it should be changed by management team, right? :)

With you and decho's help, now, I know, we can take below actions in our team:

1, set core.autocrlf = false
2, enable pre-commit hook in local

that may avoid import more and more errors.
(perhaps, it is what I can do for this moment)

[xheke]

@dscho ,

I recall what I saw at that time, the difference behavior between Linux and window:

(
assumption:
set core.autocrlf = false on window side,
enable pre-commit hook both on linux and window platform
)

On Linux side:
1, apply diff, get error message/hint
2, commit failed

On Window side:
1, apply diff, no error message ( this what i got "wrong impression" at that time)
2, commit failed

[dscho]

@xheke are you asking me something? If so, I don't understand the question...

[xheke]

Yes, is this possible provide "error message" on windows side just as on Linux side?

Thanks dscho.

[dscho]

If you set core.autocrlf = false before checking out the code, I believe that that is already the case. If not, you will have to indulge me and give another step-by-step demonstration of what you believe is a bug.