|Re: [jgit-dev] faster ref-updates where the update-type is known to be non-fast-forward|
On Sun, Aug 25, 2013 at 5:00 AM, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote:A stack overflow during a revwalk is bad. We shouldn't do this. *sigh*
> Use case: the BFG has rewritten the whole of a big repository's history, and
> needs to update the branch refs. Calling isMergedInto() can take the best
> part of a minute, and in fact it can crash the JVM with a stackoverflow
> (reported by Elliot Glaysher when using the BFG on Chromium's source).
Exception in thread "main" java.lang.StackOverflowError at org.eclipse.jgit.revwalk.MergeBaseGenerator.carryOntoOne(MergeBaseGenerator.java:205) at org.eclipse.jgit.revwalk.MergeBaseGenerator.carryOntoHistory(MergeBaseGenerator.java:194) at org.eclipse.jgit.revwalk.MergeBaseGenerator.carryOntoHistory(MergeBaseGenerator.java:195)
> Although this isn't current behaviour, perhaps setting the ReceiveCommandThere isn't a clean way to do this sort of update, but there should
> update-type to UPDATE_NONFASTFORWARD before calling BatchRefUpdate.execute()
> should be enough to tell JGit that I know the update type, and don't want
> JGit to calculate it?
be. It is completely reasonable for a calling application to say it
has already vetted the update and just wants it to proceed, provided
the reference still exactly matches the expected old SHA-1 (if
I thought it bypasses if the update-type is already set to
UPDATE_NONFASTFORWARD as you suggest, as we only run the check when
the type is the default of UPDATE.
Back to the top