From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Storm-Olsen Subject: Re: [PATCH 3/3] Teach "git branch" about --new-workdir Date: Tue, 24 Jul 2007 20:02:18 +0200 Message-ID: <46A63EAA.6080203@trolltech.com> References: <20070723035644.GC32566@spearce.org> <7v1wezohi4.fsf@assigned-by-dhcp.cox.net> <46A5B5F5.6000202@trolltech.com> <7vd4yigmla.fsf@assigned-by-dhcp.cox.net> <46A5DF1F.2030307@trolltech.com> <46A5FDF0.3060801@trolltech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig89AF8D71F9B8A7C267882B9E" Cc: Junio C Hamano , "Shawn O. Pearce" , Julian Phillips , git@vger.kernel.org To: Johannes Schindelin X-From: git-owner@vger.kernel.org Tue Jul 24 20:02:30 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1IDOiL-0002tQ-MD for gcvg-git@gmane.org; Tue, 24 Jul 2007 20:02:30 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754236AbXGXSCZ (ORCPT ); Tue, 24 Jul 2007 14:02:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753909AbXGXSCZ (ORCPT ); Tue, 24 Jul 2007 14:02:25 -0400 Received: from esparsett.troll.no ([62.70.27.18]:56148 "EHLO esparsett.troll.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753423AbXGXSCY (ORCPT ); Tue, 24 Jul 2007 14:02:24 -0400 Received: from esparsett.troll.no (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DBCB07423F; Tue, 24 Jul 2007 20:02:20 +0200 (CEST) Received: from [172.20.1.78] (unknown [172.20.1.78]) by esparsett.troll.no (Postfix) with ESMTP id 9665774191; Tue, 24 Jul 2007 20:02:20 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 Thunderbird/2.0.0.5 Mnenhy/0.7.5.666 In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=34EB4437 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEXU1NTAwMABAQGsrKyE hIQwMDAEBAS8hGUfAAACQUlEQVQ4jV2TS47cMAxEKSDZW1CfwMB4PYLkrKchsveJRR2gEen+R0hR 9vziBmahhyqSRQ4NfF1FmIv3dH4usNAGoFprBVguQJmZ1nX0XiHgEukTCK3TairiZeXcVGzmZIoU 3738pehdVbiU9KFgMQWeZ1fpHZDfRS4rPb3eQVaZChGx4ikt5GDkAZQ2KKohzjklno4+iJpVhxka ZjSpasJ4gdGaEQMWTMjRa5uTqza0XDJjzhIdzGTMrqoopimoIPCKZtVOq265MAXpMLXycmVl2Y8C oE1FkT/faKauOjYoHJyOxHfvixjowvI0xZJsKykubgLYzuJMdBO+L86TjxfQ9hz9jpSudbnXXzRm tor5i3MUONpOfARAhlWbzWF7OhP2eSeEW9HUBNiHOxUM8HLWHhUAj3NZNsdqRZpNA+DJ+XlX+Qc9 Z4ZjHX8LRUzgTBBef84NQoCMOcS0+BMsj3klbTzRri03ugXr9em1GfgzDAyEn4J3fvFI5YwdTrYu 1ntAY1h5ysM2OMGm+cBOocCXHisAHu2PagnLghoG2krz8bzsA4fj7KxCGk+63jt+DDCtYjbFNkHD nRwpRqsQYx5WYzsbm/eBfn0I4TbOGvMWqhQAiEDzNs4apumCI0x2OyHtY7uAlZff/sanbH9+AGT1 KOEmUlJISdYPgEgehw+cTZEf6xeFyoEjCPgv+A62KhW3EOy9PL7WmCBMRWmfYN0OqW9krzl/Ay91 75HMqfDtP8UFckFUX2rwrm/kTVB2gH+hdu4avZVCuAAAAABJRU5ErkJggg== Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89AF8D71F9B8A7C267882B9E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> So, it's look like this ('yes' mean CRLF EOL): >> Repo | Working dir | Convert EOL? >> --------------------------------- >> 1) - LF no >> 2) - CRLF yes >> 3) LF LF no >> 4) LF CRLF yes >> 5) CRLF LF no >> 6) CRLF CRLF yes >> >> The problem is that currently 6) is 'yes', and turns the file into >> a LF file, which it shouldn't. >=20 > Shouldn't it? But then you should set core.autocrlf =3D false, no? >=20 > AFAIU the purpose of autocrlf is to _always_ have UNIX line endings > in the checked in stuff. I realize that I might be talking 'out of context', so to speak; so it's hard to see where I'm going with this. So, I'll start from the beginning. :-) 1) IMO, git should on Windows always do CRLF conversion, as this is what Windows developers in general expect. (CRLF text-files that is, not the conversion.) Meaning that core.autocrlf =3D Windows by default. Where 'Windows' would be of true/false value which is true when on Windows and false when on other platforms. (Not that we should _have_ such an option, but the concept at least.) 2) Most Windows developers in the category above currently do git-config --global core.autocrlf true once, and be done with it. However, for every text-file they want in the repo which _should_ contain CRLF EOLs they would have to add this file to either a =2Egitattributes file in that same directory, or to .git/info/attributes with the -crlf to ensure that the autocrlf conversion is not triggered for those files. Now, for Unix users that seems like a small price to pay, and of course _they_ don't have to worry about it. It's up to the Windows developers to take the pain and add these .gitattributes files, and keep track whenever new CRLF files appear in the repo from other non-Windows developers. 3) My suggestion in the previous mail would to a large extent alleviate this problem, since once in the repo with CRLF lineendings the 'autocrlf conversion' routine wouldn't automatically try to convert it back to LF endings, even if this file is not in any attributes file with '-crlf'. It would mean that we wouldn't have to add _any_ files to attributes files at all, but only have to teach git a way to avoid crlf-converting a given file when commiting a change. For example, on Windows you could then do something like: git update-index --crlf my_DOS_file.txt git commit -m "Add a CRLF file to the repo" then forget about it. No need to add a .gitattributes in your own repo. No need for linux users to worry about Windows users. No need to Windows users to clean up the repos for the linux users. IMO, the .gitattributes file with ' -crlf' is a hack-fix to a problem we shouldn't be having in the first place. We should be able to write in the git documentation: "Text files are stored with Unix line ending in Git. If you need a text file to contain DOS line endings on all platforms, use the --crlf option on the update-index command."... or something to that effect. Ok, a bit longer mail than I expected/wanted, but I hope it explains the idea successfully, and convincingly. ;-) Later! -- =2Emarius --------------enig89AF8D71F9B8A7C267882B9E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFGpj6sKzzXl/njVP8RAsN9AJ4upWLOKDwfvIykTbJUJKC/mQpIDgCghrII zLWLoqdyFfaTYT3KXnKBi6w= =n6gl -----END PGP SIGNATURE----- --------------enig89AF8D71F9B8A7C267882B9E--