From: Dmitry Potapov <dpotapov@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
Date: Thu, 24 Jul 2008 20:53:35 +0400 [thread overview]
Message-ID: <20080724165335.GW2925@dpotapov.dyndns.org> (raw)
In-Reply-To: <7vej5kfs0w.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 23, 2008 at 10:07:43AM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, if you want to avoid CRs to _enter_ the repository, when you have
> > a lot of binary files tracked, you _do_ want to force all repositories to
> > crlf=input.
>
> If you are on a sane system, you do not even want to pay the price of
> conversion.
If you do not have CRLF then there will be no conversion, so you pay only
the price of check. The relative cost of that check obviously depends on
what other operations are. I believe that the worst case for this check
will be when there is no other operations, just re-reading files, so I
did:
# touch all files to force git re-read them...
git ls-files | xargs touch
time git status
Here is the average based on 3 attempts:
0.232s with autocrlf=false
0.265s with autocrlf=input (14% increase)
Of course, without touching files, git-status will take the same time in
both cases (about 0.026s in my testing), and touching all files not very
interesting from the practical point of view.
So, I decided to do something more practical, like applying 100 patches.
Here are my results:
false input
------ -------
7.409s 7.603s
7.592s 7.239s
7.617s 7.402s
------ -------
Average: 7.539s 7.415s
autocrlf=input turned out to be even slightly faster, but the difference
is not statistically significant.
So, though it is obvious that autocrlf=input clearly adds some overhead,
I believe it is negligable in most practical cases as there are much
more expensive operations. And you can always turn autocrlf off, if you
are sure that you never have files with the wrong line ending.
> Only people on systems with CRLF line endings should pay the
> price (because your aim is to convert on such systems).
Unfortunately, it is not so clearly cut. Some people may work on Unix
but share files with Windows using network shares or emails.
> Are we throwing
> that out of the window when the project decides to use gitattributes?
I am not sure that I understand your question. In any case, Dscho's
patch did not change the default, so it did not penalize anyone except
explicitly asked about that by setting crlf on some files. I would like
also to notice that setting crlf on some files (in contrast to unsetting
it!) is rarely necessary in practice if all users have sane settings for
autocrlf.
>
> How about setting autocrlf automatically on mingw/msys/cygwin versions,
> perhaps via templates or a patch to init-db? Would that, combined with
> user education, be a viable alternative?
Perhaps, it is good compromise for now, considering that Windows users
have most troubles with that... I really don't mind seeing 'input' as
default on other platforms, but I won't insist on that.
Dmitry
next prev parent reply other threads:[~2008-07-24 16:54 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-22 21:56 [PATCH] Respect crlf attribute even if core.autocrlf has not been set Johannes Schindelin
2008-07-22 23:11 ` Dmitry Potapov
2008-07-22 23:23 ` Johannes Schindelin
2008-07-23 0:14 ` Dmitry Potapov
2008-07-23 0:12 ` Junio C Hamano
2008-07-23 1:10 ` Johannes Schindelin
2008-07-23 1:31 ` [PATCH] Respect crlf attribute in "git add" " Johannes Schindelin
2008-07-23 5:49 ` Steffen Prohaska
2008-07-23 9:02 ` Johannes Schindelin
2008-07-23 11:40 ` Dmitry Potapov
2008-07-24 6:06 ` Steffen Prohaska
2008-07-24 12:39 ` Johannes Schindelin
2008-07-24 17:05 ` Dmitry Potapov
2008-07-24 14:09 ` Dmitry Potapov
2008-07-24 14:38 ` Johannes Schindelin
2008-07-24 14:52 ` Steffen Prohaska
2008-07-24 16:44 ` Avery Pennarun
2008-07-24 16:45 ` Johannes Schindelin
2008-07-24 20:44 ` Robin Rosenberg
2008-07-24 23:58 ` Johannes Schindelin
2008-07-23 17:07 ` [PATCH] Respect crlf attribute " Junio C Hamano
2008-07-23 17:22 ` Johannes Schindelin
2008-07-23 18:04 ` Joshua Jensen
2008-07-23 18:33 ` Avery Pennarun
2008-07-23 18:57 ` Johannes Schindelin
2008-07-23 19:20 ` Eyvind Bernhardsen
2008-07-23 19:44 ` Johannes Schindelin
2008-07-24 21:30 ` Eyvind Bernhardsen
2008-07-25 0:01 ` Johannes Schindelin
2008-07-25 12:30 ` Eyvind Bernhardsen
2008-07-25 14:01 ` Dmitry Potapov
2008-07-25 21:05 ` Eyvind Bernhardsen
2008-07-26 2:09 ` Johannes Schindelin
2008-07-29 19:11 ` Eyvind Bernhardsen
2008-07-29 13:46 ` Dmitry Potapov
2008-07-29 21:17 ` Eyvind Bernhardsen
2008-07-30 5:35 ` Steffen Prohaska
2008-07-30 18:33 ` Avery Pennarun
2008-07-30 19:25 ` Steffen Prohaska
2008-07-30 21:07 ` Avery Pennarun
2008-07-30 22:02 ` Dmitry Potapov
2008-07-30 22:14 ` Avery Pennarun
2008-08-03 16:54 ` Tarmigan
2008-08-03 17:33 ` Dmitry Potapov
2008-08-03 18:54 ` Tarmigan
2008-08-04 16:06 ` Dmitry Potapov
2008-07-30 21:45 ` Dmitry Potapov
2008-08-02 12:51 ` Eyvind Bernhardsen
2008-08-03 16:21 ` Dmitry Potapov
2008-07-23 19:22 ` Robin Rosenberg
2008-07-23 19:35 ` Junio C Hamano
2008-07-23 19:41 ` Johannes Schindelin
2008-07-23 19:33 ` Dmitry Potapov
2008-07-23 19:23 ` Junio C Hamano
2008-07-23 20:07 ` Johannes Schindelin
2008-07-24 16:53 ` Dmitry Potapov [this message]
2008-07-24 17:14 ` Johannes Schindelin
2008-07-24 17:55 ` Dmitry Potapov
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=20080724165335.GW2925@dpotapov.dyndns.org \
--to=dpotapov@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).