Re: [PATCH/RFC v2 1/4] Add "core.eolStyle" variable to control end-of-line conversion
- From
Dmitry Potapov <dpotapov@gmail.com>
- Date
- May 10, 2010, 13:46 UTC
- Message-ID
- <20100510134655.GE14069@dpotapov.dyndns.org>
- In-Reply-To
- <20100510111438.GA15206@pvv.org>
On Mon, May 10, 2010 at 01:14:39PM +0200, Finn Arne Gangstad wrote:
Show 7 quoted lines
> On Mon, May 10, 2010 at 12:13:58PM +0400, Dmitry Potapov wrote: > > > > First of autocrlf is safe as it is implemented now. > > No, it isn't. autocrlf as it is implemented now is destructive for any > file that contains CRLF in the repo (it also gives dirty files after > checkout and so on).
It may give dirty files in your working tree, but you do not lose any information silently (as it happened with CVS), so it is safe in this respect.
Show 7 quoted lines
> > > I believe that the right solution is to be able to enable autocrlf but > > only for those repositories that are marked as autocrlf compatible by > > upstream. > > Yes absolutely. But how do you tell autocrlf that the repository is > compatible with it? This is what is causing all the problems.
I suppose the original design assumption of autocrlf was that nearly all repo should be compatible, because autocrlf is very good on detecting text files. The problem with that is that many people want to store text files with different endings, but they cannot be bothered to add a few lines to .gitattributes. And while it is possible now to disable autocrlf in any repo just by adding one line to .gitattributes: * -crlf but it is impossible to say the opposite.
So, I believe we should add "crlf=auto" as Eyvind proposed, as well as to do eol conversion for files marked as "crlf" even if autocrlf is not set as Linus suggested earlier. (Certainly, "eolconv" would be a better name than "crlf", but maybe it is not the right time to replace it right now).
> > Now, I propose to change autocrlf in such a way that it will work as > before for all repositories that are "compatible with it", but _also_ > so that it works reasonably with those that aren't.
No, you proposed something different. You said that conversion for new files would become optional. I don't know what exactly you mean by optional, but it sounds incompatible with what we have now. In fact, what I really like about autocrlf is that I do not need to think about when I add a new file.
Moreover, you said "Convert LF-only text files to CRLF on checkout", which raises two questions:
1. Where should information about what file was and what was not converted be stored? (Storying it in the index can make the index incompatible with old versions of Git).
2. How does it solve the problem with new files? (Just saying that this conversation will be optional, does not it mean that it will be right for this particular repo.)
Dmitry