git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clemens Buchacher <drizzd@aon.at>
To: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Cc: Finn Arne Gangstad <finnag@pvv.org>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: What's cooking extra
Date: Tue, 25 May 2010 00:11:28 +0200	[thread overview]
Message-ID: <20100524221128.GA29588@localhost> (raw)
In-Reply-To: <986EE696-5997-40AD-929C-D82D40D7242E@gmail.com>

On Mon, May 24, 2010 at 11:11:40PM +0200, Eyvind Bernhardsen wrote:

> If you later discover that you want normalized text files in your
> repository, you _will_ have to convert all your files.  That's a
> bit tricky, but it's not the huge problem you're making it out to
> be, and it only has to be done once.

I am not just making this stuff up. These things have bitten me in
the past, and there have been complaints about it in #git. And even
after finding the solution I always felt like crlf handling in git
was really broken. I was hoping that after enabling the new eol
handling, these weird effects would go away, but obviously they
don't.

Maybe for you it does not seem like such a big deal, because you
are now so familiar with the inner workings of this algorithm. But
to a naive user like me it is very counter-intuitive.

I am not saying that the new features are all wrong. Some of them
really are a major improvement. My main point is that it is still
confusing and that in itself will cause issues for many people.

And I don't see why we cannot do better. In the first scenario of
my previous post (no attributes set), since I already enable
core.eol = lf, couldn't we handle that as if text=auto were set on
every file?  Isn't that what core.autocrlf = true means in this
case?

And once we normalized the file to LF, why don't we also checkout
that version, or at least mark it as dirty in the index, so a reset
--hard will fix it up?

Regards,
Clemens

  reply	other threads:[~2010-05-24 22:11 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 14:33 What's cooking extra Junio C Hamano
2010-05-19 15:12 ` A Large Angry SCM
2010-05-19 17:06 ` Finn Arne Gangstad
2010-05-19 20:09   ` Eyvind Bernhardsen
2010-05-22 13:09   ` Clemens Buchacher
2010-05-22 19:42     ` Eyvind Bernhardsen
2010-05-22 22:27       ` Clemens Buchacher
2010-05-23 10:36         ` Eyvind Bernhardsen
2010-05-23 11:51           ` Clemens Buchacher
2010-05-23 12:53             ` Eyvind Bernhardsen
2010-05-23 13:26               ` Ævar Arnfjörð Bjarmason
2010-05-24  9:49               ` Clemens Buchacher
2010-05-24 12:47                 ` Dmitry Potapov
2010-05-24 20:45                   ` Eyvind Bernhardsen
2010-05-24 20:56                   ` Clemens Buchacher
2010-05-24 21:09                     ` Eyvind Bernhardsen
2010-05-24 21:11                 ` Eyvind Bernhardsen
2010-05-24 22:11                   ` Clemens Buchacher [this message]
2010-05-25  6:41                     ` Eyvind Bernhardsen
2010-05-25  8:27                       ` Anthony Youngman
2010-06-07 19:55                         ` Eyvind Bernhardsen
2010-05-25  8:33                       ` Clemens Buchacher
2010-05-24 12:12             ` Dmitry Potapov
2010-05-24 12:22               ` Erik Faye-Lund
2010-05-24 12:42                 ` Dmitry Potapov
2010-05-21 16:16 ` Ævar Arnfjörð Bjarmason
2010-05-22 21:24 ` René Scharfe
2010-05-22 21:26   ` [PATCH 1/8] grep: add test script for binary file handling René Scharfe
2010-05-22 21:28   ` [PATCH 2/8] grep: grep: refactor handling of binary mode options René Scharfe
2010-05-22 21:29   ` [PATCH 3/8] grep: --count over binary René Scharfe
2010-05-22 21:30   ` [PATCH 4/8] grep: --name-only " René Scharfe
2010-05-22 21:32   ` [PATCH 5/8] grep: use memmem() for fixed string search René Scharfe
2010-05-22 21:34   ` [PATCH 6/8] grep: continue case insensitive fixed string search after NUL chars René Scharfe
2010-05-22 21:35   ` [PATCH 7/8] grep: use REG_STARTEND for all matching if available René Scharfe
2010-05-22 21:43   ` [PATCH 8/8] grep: support NUL chars in search strings for -F René Scharfe

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=20100524221128.GA29588@localhost \
    --to=drizzd@aon.at \
    --cc=eyvind.bernhardsen@gmail.com \
    --cc=finnag@pvv.org \
    --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).