git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marius Storm-Olsen <marius@trolltech.com>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Julian Phillips <julian@quantumfyre.co.uk>,
	git@vger.kernel.org
Subject: Re: [PATCH 3/3] Teach "git branch" about --new-workdir
Date: Wed, 25 Jul 2007 08:47:57 +0200	[thread overview]
Message-ID: <46A6F21D.2010306@trolltech.com> (raw)
In-Reply-To: <20070724231529.GA29156@steel.home>

[-- Attachment #1: Type: text/plain, Size: 6757 bytes --]

Alex Riesen said the following on 25.07.2007 01:15:
> Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:
>> 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.
> 
> I have to stay with Windows, but I'd absolute hate having their stupid
> line-ending by default. As will my project supervisor, and he gets
> changes from something like 300 developers. You will definitely get
> their votes against changing the default

Ok, so maybe not changing the default.
Though it's weird behavior for _most_ Windows developers out there, I 
agree that the current Windows Git population would mostly prefer the 
Unix line endings. And I can see how someone who's working on Windows 
and handling a lot of patches from other developers of multiple OSs 
also wanting the non-platform-standard Unix line-endings.
I still would argue that it's not the norm. Currently yes, in the 
foreseeable future, I doubt it.


>>> Git is really slowed down tremendously just by the fact that it runs on 
>>> 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.. :-)
> 
> Of course you wont notice it: you're already on Windows.

Come on, when did a search and replace in a normal size source file 
take any time? It's really not an argument for not doing CRLF 
conversion on a platform that creates CRLF files by default!

If you want files to be stored in the repo with Unix line-endings, 
which I expect most people would want, to share it with other 
non-Windows developers, you _have_ to do it. (No, not the MSys/Cygwin 
users)


>>> IMHO in most cases -- even on Windows -- you do not want to set autocrlf 
>>> at all.  Because you do not need to store the file different from the 
>>> 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.
> 
> Yes. They solve it by working fulltime in \n-lineending. Avoiding that
> stupid Visual Studio and Notepad helps too.

Huh? You just removed more than 3 _million_[1] potential users.. (Some 
say 8 million [2]) Is that a good argument? Why should developers on 
Windows avoid using Windows tools? Because they're 'idiots'? (ref 
further down in your reply)

Anyways, even if a tool on Windows _handles_ LF line-endings perfectly 
fine, most of these tools still create CR/LF files when you create a 
new text file.
(No, again not the MSys or LF-configured Cygwin vim/emacs/<insert your 
favorite unix editor here>. But the native editors which handles both 
formats. There's plenty of those too.)


>>> The only situation where I think it makes sense, is when you have both 
>>> Windows and Unix developers, _and_ your Windows tools sometimes produce 
>>> 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.
> 
> Just make the windows installer to setup templates for CR/LF depending
> on checkbox "[ ] I am Windows idiot, standard issue".

Mmm, ok. If I'm an idiot just for using Windows, I guess the battle is 
lost already.


>> 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.
> 
> It is for me. It will not be that with your suggested default.

Then I wouldn't put you in the normal Windows developer category, but 
rather the one which is dependent on MSys or Cygwin, and live in 
bash/zsh on Windows. I would argue that most of those 3/8 million VS 
users are not in the same category as you.

But sure, I don't mind having to set core.autocrlf=true when I 
configure Git, but then I would like that mode to work without the 
extra hassle. (Most people don't want to change already incorporated 
options, which is fully understandable)


>> 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
> 
> You always setup the lineending conversion in perforce. For each and
> every client. There is no default. I just don't see what to learn from
> them (if there ever was something to learn from).

No you don't. You _can_, but the default when you create a 'client 
spec' is the platform specific line endings. Only 'Unix' users working 
on Windows really take the trouble of changing the line endings to 
they work with their MSys or Cygwin enviroments.


>> ... And Git would probably be adapted on
>> Windows more quickly, which this is all about. :-) IMHO.
> 
> It is hardly worth it. Git already has to put up with ugly workarounds
> just because of the stupidities coming from that windows. It has had
> seldom any benefit from supporting this !@#$ing awkward platform.

Well, I guess with this opinion there really no point in me trying to 
prove a point. If all Windows users are 'idiots' on a '!@#$ing 
awkward' platform, I'm probably just an 'idiot' trying to help out.

I hope it's not the general opinion of the Git team that Windows users 
should just bugger off..

Now, personally I don't have a problem with all this line ending 
stuff. I work on Windows and Unix on a daily basis, addicted to MSys 
and Cygwin for performing my daily tasks, and use tools which handles 
LF and CR/LF interchangeably without any problems. So, the current 
state of Git works for me. I'm just trying to help figuring out what 
we can do to make the tool even more platform agnostic, and work as 
expected.


[1] http://msdn.microsoft.com/vsip
[2] http://www.regdeveloper.co.uk/2007/06/09/vs_shell_eclipse/

-- 
.marius


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

  reply	other threads:[~2007-07-25  6:47 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-22 18:56 [PATCH 3/3] Teach "git branch" about --new-workdir Johannes Schindelin
2007-07-22 19:16 ` Daniel Barkalow
2007-07-22 19:24   ` Johannes Schindelin
2007-07-22 21:09 ` Julian Phillips
2007-07-22 21:25   ` Johannes Schindelin
2007-07-22 21:50     ` Julian Phillips
2007-07-22 21:59       ` Johannes Schindelin
2007-07-22 22:24         ` Julian Phillips
2007-07-22 22:46           ` Jakub Narebski
2007-07-22 23:37             ` Johannes Schindelin
2007-07-22 23:02           ` Johannes Schindelin
2007-07-23  3:56             ` Shawn O. Pearce
2007-07-23  4:45               ` Junio C Hamano
2007-07-23  5:14                 ` Shawn O. Pearce
2007-07-23  5:22                   ` Shawn O. Pearce
2007-07-23 10:32                 ` Johannes Schindelin
2007-07-23 10:42                   ` Johannes Schindelin
2007-07-24  8:19                 ` Marius Storm-Olsen
2007-07-24  9:02                   ` Johannes Schindelin
2007-07-24  9:47                     ` Junio C Hamano
2007-07-24 11:07                       ` Johannes Schindelin
2007-07-24 11:14                       ` Marius Storm-Olsen
2007-07-24 12:06                         ` Julian Phillips
2007-07-24 12:28                           ` Marius Storm-Olsen
2007-07-24 12:37                           ` Johannes Schindelin
2007-07-24 13:47                             ` Josef Weidendorfer
2007-07-24 13:54                               ` Johannes Schindelin
2007-07-24 14:21                                 ` Josef Weidendorfer
2007-07-25  0:09                           ` Jakub Narebski
2007-07-24 12:42                         ` Johannes Schindelin
2007-07-24 13:26                           ` Marius Storm-Olsen
2007-07-24 13:29                             ` Marius Storm-Olsen
2007-07-24 13:33                             ` Johannes Schindelin
2007-07-24 18:02                               ` Marius Storm-Olsen
2007-07-24 18:30                                 ` Johannes Schindelin
2007-07-24 19:36                                   ` Marius Storm-Olsen
2007-07-24 23:15                                     ` Alex Riesen
2007-07-25  6:47                                       ` Marius Storm-Olsen [this message]
2007-07-25  9:39                                         ` Johannes Schindelin
2007-07-25 10:22                                           ` Steven Grimm
2007-07-25 11:05                                           ` Andy Parkins
2007-07-25 12:10                                             ` Marius Storm-Olsen
2007-07-25 14:09                                               ` Johannes Schindelin
2007-07-25 20:40                                             ` Linus Torvalds
2007-07-26 11:51                                               ` Christian MICHON
2007-07-23  8:31             ` Julian Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A6F21D.2010306@trolltech.com \
    --to=marius@trolltech.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=julian@quantumfyre.co.uk \
    --cc=raa.lkml@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).