Re: crlf issues
- From
- Rusi Mody <rustompmody@gmail.com>
- Date
- Jun 20, 2015, 06:21 UTC
- Message-ID
- <d9cb6527-e137-4b55-95e6-c3d08557d905@googlegroups.com>
- In-Reply-To
- <06bed56e-b934-43e1-af1e-df1253c07dac@googlegroups.com>
On Friday, June 19, 2015 at 8:59:19 PM UTC+5:30, Rusi Mody wrote:
Show 71 quoted lines
> > > > On Friday, June 19, 2015 at 7:41:00 PM UTC+5:30, Johannes Schindelin wrote: >> >> Hi Rusi, >> >> Cc:ing the main Git list, as some of this has been discussed at the >> GitMerge in Paris, and some participants of that discussion might want to >> join this thread. >> >> On 2015-06-19 14:55, Rusi Mody wrote: >> > Trying to setup git. >> > Majority folks are MS VS users but also some *nixers. >> > >> > My current understanding/analysis of the situation: >> > >> > 1. autocrlf is broken -- keep it false >> > 2. safecrlf is a cure (to some extent) -- keep it true >> > 3. core.eol can be left native (or is crlf on windows/lf on *nix >> > preferred??) >> > >> > And of course most crucial: >> > 4. Make sure ALL file types are covered in .gitattributes; eg >> > >> > *.txt text >> > *.cs text >> > : >> > : >> > *.pdf binary >> > etc >> > >> > Still when we get a merge conflict the file (created by git with >> conflict >> > markers) shows ^M in vi >> > ie I assume its unclean line endings. >> > >> > Any tips what to do? >> >> The most important preliminary question is: how cross platform is your >> project? > > > Somewhat complex question... > Almost completely windows as of now. > Good chance of starting to migrate to Linux shortly... little by little > and would like to minimize future headches. > > >> If there is no risk of any developer working on a non-Windows platform, >> you could simply commit CRLF and be done with it. >> > > Ok. So what are the (set of) settings for that? > - MS-only project > - No conversions any which way > seems to be a better starting compromise than broken to start with :-) > > > As to autocrlf: I actually had some good experience with setting it to >> `input` when working with other developers. >> > > > Can hardly claim to be expert on this but general impression I got from > searching the net is autocrlf is more broken than working > and so best avoided > eg > > http://stackoverflow.com/questions/2333424/distributing-git-configuration-with-the-code/2354278#2354278 >
I think I need to retract my complaint: Tried a couple of times -- windows and linux. Linux: there was never an issue Windows: If the file-suffix is listed as text in .gitattributes there is no issue If not listed then the merge-conflict marked file is messed up – ie emacs shows it as (Unix) with ^M on all lines except the lines with conflict-markers added.
What I had earlier done different I am not quite sure... So to ask again about strategy: This is what seems to be working: - core.eol native (leave as is) - core.autocrlf false - core.safecrlf true - List all textish files in gitattributes (if not gitignore)
What I miss: A 'super-safecrlf' option which would would error-out upon any file not explicitly listed in gitattributes as binary or text getting added.
Is there something like this?
-- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.