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 21:36:06 +0200 Message-ID: <46A654A6.5070802@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> <46A63EAA.6080203@trolltech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C0FA63E0BD519D9A311970A" 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 21:36:36 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 1IDQBQ-0003VD-10 for gcvg-git@gmane.org; Tue, 24 Jul 2007 21:36:36 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755558AbXGXTgV (ORCPT ); Tue, 24 Jul 2007 15:36:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756422AbXGXTgV (ORCPT ); Tue, 24 Jul 2007 15:36:21 -0400 Received: from esparsett.troll.no ([62.70.27.18]:47030 "EHLO esparsett.troll.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754347AbXGXTgT (ORCPT ); Tue, 24 Jul 2007 15:36:19 -0400 Received: from esparsett.troll.no (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4712274283; Tue, 24 Jul 2007 21:36:18 +0200 (CEST) Received: from [172.20.1.78] (unknown [172.20.1.78]) by esparsett.troll.no (Postfix) with ESMTP id C874A74288; Tue, 24 Jul 2007 21:36:17 +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) --------------enig5C0FA63E0BD519D9A311970A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> 1) IMO, git should on Windows always do CRLF conversion, as this is wh= at >> Windows developers in general expect. (CRLF text-files that is, not th= e >> conversion.) Meaning that >> core.autocrlf =3D Windows >=20 > I do not think so. >=20 > core.autocrlf is only about the relationship between the working tree a= nd=20 > the repository. >=20 > So if you want CR/LF line endings always, just do not set that flag=20 > (which defaults to false). >=20 > If you want LF line endings in the repo, but not necessarily in the=20 > working tree, set core.autocrlf to input. >=20 > If you want LF line endings sometimes, but CR/LF at other times, but do= =20 > not care if the revisions in the repository will have LF or CR/LF, do n= ot=20 > set that flag. Ok, here we fundamentally disagree. IMO Windows user expect files to be DOS style, since all other files are. Yes, most newer tools 'handle' Unix style files, but creating new ones will mostly be DOS style. Some will actually wreak havoc on your files, and start adding DOS line endings in the middle of your Unix line ending file. I've seen it happen. So, dealing with Unix style text files on Windows can be a problem for some people. So, normally, when developing on Windows you'd expect DOS files, nothing else. (Note that we're not talking about your average MinGW or Cygwin user here, since they are known to the issues and how to tackle them) > Git is really slowed down tremendously just by the fact that it runs on= =20 > Windows. You should not add to that. The auto crlf conversion is not the slow down here, and the time spent there is negligible. I use autocrlf on all my repos on Windows, and don't notice it. Filestat'ing on the other hand.. :-) > IMHO in most cases -- even on Windows -- you do not want to set autocrl= f=20 > at all. Because you do not need to store the file different from the=20 > version you have in the working tree. Not true. I believe, especially at the moment, most Git users on Windows are mostly developing code in a cross-platform manner, and therefore care about this problem. > The only situation where I think it makes sense, is when you have both = > Windows and Unix developers, _and_ your Windows tools sometimes produce= =20 > CR/LF stupidly. But then I'd set it to "input". That's ok _now_, because most of the Git user group is experienced developer that understand the problem. I'm trying to see past that state, and prepare Git for more 'common' usage on Windows. They'd expect text files on Windows to be handled correctly, without any fuzz. No tweaking of config options to make it work on Windows. No problems with sharing repositories with Unix developers. Just work. That's not the current state. But it could be. > BTW no need to fuzz about binary files, which want to be in the > object database without being converted. Our heuristics has so far > been pretty successful in discerning binary from text files. Yeah, I have no beef with the binary detection. It seems to work fine. At least I haven't had a problem with it yet, and it's not what we're discussing. Ok, I come from the Perforce world, so here how it works there: 1) Files are stored with Unix line endings in the repository. 2) Conversion is done on Windows (and older Macs) upon checkout, if the file is a text file. 3) It has binary file detection when you add it to the depot, so if you and to add a DOS line ending file to the repo, you have to mark it as a binary file manually Git does 1) and 2) already, and with the EOL detection in the repo file, (when you've already detected that a file has changed, so there's not much time wasted with that) to eliminate the 'yes' in point 6) in the original mail, should help implement 3) above well enough. It's simply, "If it was a CRLF file before, no need to convert it to LF now", and the problem is largely fixed. Then it's only when we want to commit a new CRLF file that we need a way to 'turning off' the autocrlf for just _that_ file for _that_ commit. And presto, you'd have something which most Windows users would expect. And Git would probably be adapted on Windows more quickly, which this is all about. :-) IMHO. -- =2Emarius --------------enig5C0FA63E0BD519D9A311970A 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) iD8DBQFGplSxKzzXl/njVP8RAuw0AJ9BFaRrl+0bsaP+xrozuIpeG/31uQCdFUAJ /wJPGBMV+8g8w1KPhcQA7Ng= =I1F6 -----END PGP SIGNATURE----- --------------enig5C0FA63E0BD519D9A311970A--