> On 24 Oct 2017, at 20:14, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi, > > Lars Schneider wrote: > >> I've migrated a large repo (110k+ files) with a lot of history (177k commits) >> and a lot of users (200+) to Git. Unfortunately, all text files in the index >> of the repo have CRLF line endings. In general this seems not to be a problem >> as the project is developed exclusively on Windows. > > Sounds good. > >> However, I wonder if there are any "hidden consequences" of this setup? >> If there are consequences, then I see two options. Either I rebase the repo >> and fix the line endings for all commits or I add a single commit that fixes >> the line endings for all files. Both actions require coordination with the >> users to avoid repo trouble/merge conflicts. The "single fixup commit" options >> would also make diffs into the past look bad. Would a single large commit have >> any impact on the performance of standard Git operations? > > There are no hidden consequences that I'm aware of. If you later > decide that you want to become a cross-platform project, then you may > want to switch to LF endings, in which case I suggest the "single > fixup commit" strategy. > > In any event, you also probably want to declare what you're doing > using .gitattributes. By checking in the files as CRLF, you are > declaring that you do *not* want Git to treat them as text files > (i.e., you do not want Git to change the line endings), so something > as simple as > > * -text That's sounds good. Does "-text" have any other implications? For whatever reason I always thought this is the way to tell Git that a particular file is binary with the implication that Git should not attempt to diff it. Thanks, Lars
