Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] faster ref-updates where the update-type is known to be non-fast-forward

When using JGit to perform a ref-update that I know is a non-fast-forward update, I'd like to be able to tell JGit to not perform the expensive revWalk.isMergedInto() calculations used to superfluously determine whether the update is in fact fast-forward or not.

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).

There are two places where revWalk.isMergedInto() is called during a batch-ref-update:

https://github.com/eclipse/jgit/blob/9b26e4bff/org.eclipse.jgit/src/org/eclipse/jgit/transport/ReceiveCommand.java#L292-L299

I couldn't figure out a good way (using the current JGit API) to avoid these calls getting made (or to maybe tell JGit to not search so deep?), and eventually used the workaround of sub-classing RevWalk and overriding isMergedInto() with a short-circuit function:


This felt like a bit of a hack - does anyone have any better solutions?

Although this isn't current behaviour, perhaps setting the ReceiveCommand 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?

best regards,
Roberto

https://github.com/rtyley/bfg-repo-cleaner/issues/23


Back to the top