Re: [PATCH 3/3] Revert "git-svn: always initialize with core.autocrlf=false"
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- Mar 4, 2010, 10:24 UTC
- 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 <normalperson@yhbt.net> wrote:
Show 19 quoted lines
> Erik Faye-Lund <kusmabite@googlemail.com> wrote: >> On Wed, Mar 3, 2010 at 9:10 PM, Erik Faye-Lund <kusmabite@googlemail.com> 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