Skip to content

Git merge support can lead to long index times #3367

@cesar-d2l

Description

@cesar-d2l

Describe the bug
OpenGrok version: 1.5.7
OpenJDK version: Amazon Corretto 11
OS: Amazon Linux 2
ctags version: p5.9.20201108.0
Tomcat version: 9.0.39

We are updating our OpenGrok 1.3.16 instance to the latest (1.5.7 as of this writing) but have noticed that the initial time to index jumped from roughly a half-hour to 4.5 hours.

It spends a lot of time in this command: git log --abbrev-commit --abbrev=8 --name-only --pretty=fuller --date=iso8601-strict -m -- path/to/repo

Reading up on the updates, we noticed that OpenGrok now supports octopus merges, fixed by #3166. We think this is causing problems with our repositories branching and merging strategy. This repository doesn't use linear history (using either squash or rebasing) and most people do not rebase before merging, so there is a lot of merge commits - both to master, and from master to branches. (to make matters more complicated, this repository was created from dozens of other smaller repos in a huge history rewrite + merge commit)

Once the initial indexing is done, viewing the history of a file is now a lot more verbose. When I viewed the history from 1 file, it went from showing 2 commits to it being 12 pages long.

To Reproduce
The repository is private, so I can't offer an exact way to reproduce. But it's a fairly large repo (>300,000 commits) with lots of merge commits

Expected behavior
Two things:

  • Initial indexing when there is a lot of merge commits to not take a long time
  • The history to be an accurate reflection of what's changed for a file

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions