Hi,

On Sat, 13 Feb 2010, Eric Wong wrote:

quoted text
> Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> > If I enable core.autocrlf and perform a "git svn rebase" that fetches
> > a change containing CRLFs, the git-svn meta-data gets corrupted.
> > 
> > Commit d3c9634e worked around this by setting core.autocrlf to "false" 
> > in the per-repo config when initing the clone. However if the config 
> > variable was changed, the breakage would still occur. This made it 
> > painful to work with git-svn on repos with mostly checked in LFs on 
> > Windows.
> > 
> > This patch tries to fix the same problem while allowing core.autocrlf 
> > to be enabled, by disabling filters when when hashing.
> > 
> > git-svn is currently the only call-site for hash_and_insert_object 
> > (apart from the test-suite), so changing it should be safe.
> > 
> > Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> > ---
> > 
> > With this patch applied, I guess we can also revert d3c9634e. I didn't
> > do this in this series, because I'm lazy and selfish and thus only
> > changed the code I needed to get what I wanted to work ;)
> > 
> > I've been running git-svn with these patches with core.autocrlf enabled
> > since December, and never seen the breakage that I saw before d3c9634e.
> 
> Hi Erik,
> 
> How does reverting d3c9634e affect dcommit?  I've never dealt with (or
> even looked at) autocrlf, so I'll put my trust in you and Dscho with
> anything related to it.

I have no idea how reverting said commit affects dcommit, and I do not 
have the time to check, sorry!

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html