Re: CRLF problems with Git on Win32
- From
- Steffen Prohaska <prohaska-wjoc1khpmeg@public.gmane.org>
- Date
- Jan 8, 2008, 20:39 UTC
- Message-ID
- <FADDEA64-FFE7-4420-AC1F-19262F415BAF@zib.de>
- In-Reply-To
- <7v3at8rs4b.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Jan 8, 2008, at 9:15 PM, Junio C Hamano wrote:
Show 53 quoted lines
> > Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes: > >> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote: >>> >>> "J. Bruce Fields" <bfields- >>> uC3wQj2KruNg9hUCZPvPmw-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes: >>> >>>> My only suggestion is that we consider allowing the user that >>>> "explicitly told git to do so" be the project maintainer. So if >>>> you >>>> >>>> echo * autodetectcrlf >.gitattributes >>>> git add .gitattributes >>>> git commit >>>> >>>> then users that clone your repo will get that default without >>>> having to >>>> be told to do something magic on clone. >>>> >>>> (And ideally I'd've hoped you could do that using the existing crlf >>>> attribute rather than having to invent something new, but maybe >>>> that >>>> doesn't work.) >>> >>> I think the project can mark text files as text with attributes >>> and if the port to the platform initialized core.autocrlf >>> appropriately for the platform everything should work as you >>> described. >>> >>> At least that is how I read the description of `crlf` in >>> gitattributes(5). >> >> >> But we do not want to mark a file as text but tell git to run its >> auto-detection and use the local default line endings. > > My reading of the description of `crlf` in gitattributes(5) is: > > `crlf` > ^^^^^^ > > This attribute controls the line-ending convention. > > Set:: > > Setting the `crlf` attribute on a path is meant to mark > the path as a "text" file. 'core.autocrlf' conversion > takes place without guessing the content type by > inspection. > > > Notice "without guessing".
Exactly this is the problem. Some projects want guessing. A project needs to have a way to explicitly tell git that is should guess the file type and if it found "text", then it should use the right line endings (that is the locally preferred endings). If the project has control, the project maintainer is responsible for making the right choice. That is either he enables automatic detection of "text" files, or he can explicitly tell git about the types without guessing.
A different project may not want to have guessing at all, but leave all files as is. I believe this should be the default for all projects that do not explicitly choose otherwise. I'm still reluctant to enabling guessing as a system wide default. Someone may just want to use git to manage a few binary files locally on his machine. I'd be unhappy if "guessing" corrupted these files.
The project needs control if guessing is activated or not. Right now we have no way for a project to tell git that it should guess, even if the default for other projects is not to guess.
Steffen