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
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_TRACE=2 git svn fetch and post the output.
I'd
] 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 index error
The message unordered stage entries in index comes only when
two adjacent entries in the index are in a wrong order, e.g. test0
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 sha1 before fatal:
unorder You can then use git ls-tree sha1 to examine this tree,
try to sort the file list with LANG=C sort and compare with the
original list.
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 created
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
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 years)
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
