From: Erik Faye-Lund Date: Thu, 04 Mar 2010 10:24:02 GMT Subject: Re: [PATCH 3/3] Revert "git-svn: always initialize with core.autocrlf=false" Message-ID: <40aa078e1003040224v57bbea92w83a01f95390f5f1b@mail.gmail.com> In-Reply-To: <20100304095350.GB12885@dcvr.yhbt.net> On Thu, Mar 4, 2010 at 10:53 AM, Eric Wong wrote: > Erik Faye-Lund wrote: >> On Wed, Mar 3, 2010 at 9:10 PM, Erik Faye-Lund wrote: >> > git-svn dcommit uses diff-tree (which does not apply CRLF conversion) to >> > generate SVN commits, so there never were any CRLF conversion issues when >> > commiting in the first place. >> >> Uhm, this comment is slightly wrong. diff-tree is used to find out if >> there's a change in a file at all. cat_blob(), which in turn uses "git >> cat-file", is used to get the file contents. >> >> Sorry for the noise. > > Hi Erik, > > Yes, diff-tree is only used to find changed paths, not the actual > content changes.  git svn always uses entire blobs from cat-file. > > So cat-file won't do CRLF conversions at all, meaning this change is > safe for previously created repos, correct? Correct. But existing git-svn clones (that was cloned after d3c9634 was introduced) will still have autocrlf-conversions disabled anyway (because d3c9634 disabled it), so people shouldn't see any difference before either re-cloning or manually enabling core.autocrlf in the repo. I don't think there's any way to automatically remove the config option that d3c9634 set up without potentially stepping on the user's toes. And I have a gut-feeling that it would be wrong thing to do anyway. -- Erik "kusma" Faye-Lund