Re: [PATCH 2/2] git-svn: support fetch with autocrlf on
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 13, 2010, 23:55 UTC
- Message-ID
- <alpine.DEB.1.00.1002140054300.20986@pacific.mpi-cbg.de>
- In-Reply-To
- <20100213122532.GA31653@dcvr.yhbt.net>
Hi,
On Sat, 13 Feb 2010, Eric Wong wrote:
Show 31 quoted lines
> 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