On Fri, Mar 30, 2012 at 12:25 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Mar 30, 2012 at 08:42:04AM +0200, Johannes Sixt wrote: > >> Am 3/30/2012 4:19, schrieb Chris Harris: >> > I'm starting a new repository for a Windows-only project where I don't >> > think I want git to do any end-of-line normalization on my text files. >> > (I'm totally happy to have CRLFs both in the repo and in all the >> > working copies.) >> >> The question is rather: Are you happy if someone commits a file that does >> *not* have CRLF, but only LF? >> >> Because if you don't care, you are better off setting no attributes and no >> core.autocrlf and no core.eol at all. The git will take the file >> unmodified. If someone's editor changes the eol style of a file, it will >> be noticed because the diff will show that the entire file has changed. >> Your team mates should better have enough discipline not to ignore such a >> hint that something's gone awry, of course. > > I think it may be slightly more complex than that. He may be OK with > "git does nothing" and assuming everybody's editor does the sane thing. > But he may _not_ be OK with a stray core.autocrlf setting in a project > member's git config normalizing all line endings whenever they touch a > file. Setting "-text" prevents the latter. Yes, avoiding stray core.autocrlf settings was indeed one of my main motivations. Johannes is right that ideally a teammate is going to notice if all of us a sudden a whole file has changed. But I also believe that, if there's an easy way to prevent people from accidentally doing the wrong thing when they're tired/hurried/whatever and it has no bad side-effects, why not enable it? The problem is slightly intensified for users of msysgit on Windows; the msysgit installer guides one toward picking core.autocrlf=true as your system default. Making sure that every last teammate disables autocrlf seems potentially error-prone. > However, I find the behavior of "Git Extensions" to be questionable. I > can see the rationale for thinking that "-text" means more than just > handling line-endings, but I think "-diff" is probably a better choice > for seeing if something is binary (or even checking the "binary" macro). > Those are what git uses itself. > > Perhaps it was a mistake to call it "text", as it invites this sort of > confusion. Ok, thanks. That's helpful. A related point of confusion: I've noticed that, if you start with a question along the lines of "how can I explicitly tell git that a file is binary", then the web currently gives a slightly confusing array of answers. For example: * The Pro Git Book (http://progit.org/book/ch7-2.html) tells you to use either "binary" or "-crlf -diff" * http://www.bluishcoder.co.nz/2007/09/git-binary-files-and-cherry-picking.html tells you to use "-crlf -diff -merge" * http://www.dont-panic.cc/capi/2009/02/16/how-to-force-git-to-consider-a-file-as-binary/ tells you to use "-crlf" * "man gitattributes" has helpful info, but it's scattered across different sections. In the section "Marking files as binary", it says "The simplest way to mark a file as binary is to unset the diff attribute in the .gitattributes file". (Note: This implies that there are other ways you might also want to consider.) Under "Performing a three-way merge" you also learn that "-merge" is "suitable for binary files that do not have a well-defined merge semantics". You learn about the "binary" attribute only under the section "Defining Macro Attributes", which says that it means "-text -diff", but not in what cases you might want to use it. The section describing "text"/"-text" does not contain the word "binary" at all, so you have to infer whether it's a helpful setting for binary files. It makes me wonder if the documentation could be improved a little on this count, though I don't yet feel solid enough in my understanding to propose a particular patch. > PS I think one could potentially work around the whole issue by setting > "-crlf", which git treats equivalently to "-text" these days (and > hopefully isn't also checked by Git Extensions). Yes, that sounds like a plausible way to go. -- 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