> see these commands, or something else. Could you try again with
> GIT_TRACE=/absolute/path/to/some/where instead of GIT_TRACE=2 and post
> the content of /abso../some/where?
It looks the same as far as I can see:
$ GIT_TRACE=/tmp/git-trace git svn fetch
fatal: unordered stage entries in
sorted-lc-all are identical
________
From: McHenry, Matt
Sent: Friday, May 22, 2015 10:47 PM
To: Duy Nguyen
Cc: Junio C Hamano; git@vger.kernel.org
Subject: RE: recovering from "unordered stage entries in index" error
> So maybe you can do "GIT_
> So maybe you can do "GIT_TRACE=2 git svn fetch" and post the output.
> I'd expect to see something like "git read-tree " before "fatal:
> unorder...". You can then use git ls-tree to examine this tree,
> try to sort the file list with "LANG=C sort" and compare with the
> original list.
subtle going on here ...
> -Original Message-
> From: jch2...@gmail.com [mailto:jch2...@gmail.com] On Behalf Of Junio C
> Hamano
> Sent: Friday, May 22, 2015 15:25
> To: McHenry, Matt
> Cc: git@vger.kernel.org
> Subject: Re: recovering from "unordered stage entries in inde
> > Isn't this failure coming from git-svn that tries to write out a
> > tree after it prepared whatever it wants to record in its (possibly
> > temporary) index? I have a feeling that the index held by the end
> > user is not broken.
>
> Ahh that would explain why ls-files works. Yep.
I
> This message can be improved to show what entries have this problem.
Yes, that would definitely be a start. :)
> But then I don't see any way to recover the index manually. ls-files
> will die too. Perhaps we should be gentle in this case: show warnings
Actually, ls-files succ
Enrico asked:
> Could it be that certain files spent parts of their historical lifetime
> inside the ignored paths ?
I left out one possibly important piece of information: My initial 'git
svn fetch' used '-r' to "cauterize" the history, both because there is a lot of
it (almost 12 yea
My company has a fairly large SVN repository, and I'm running into a
bug with git-svn where some revisions aren't being fetched.
The repository has a standard trunk/tags/branches layout, but there are
some top-level directories under trunk/ that clearly don't belong in Git, and
8 matches
Mail list logo
