Don't automatically calculate diff between two branches in compare view

[sebastian-sauer]

• Gitea version (or commit ref): 1.3
• Git version: n/a
• Operating system: n/a
• Database (use [x]):
  • [x ] PostgreSQL
  • [x ] MySQL
  • [x ] MSSQL
  • [x ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist:

Description

When opening the compare-Page (to create a pull request or just compare two branches) the diff is calculated automatically.

If you're now changing one of the branches (head or base) gitea will automatically reload the page and calculate the diff again.
Depending on the amount of changes this may take a while.

Idea or suggestion would be to introduce a new "Calculate changes" button that triggers a page reload and thus prevents useless diff calculations on wrong selection of a branch or when you need to change both branch values.

In order to not break any existing workflows i'd suggust to calculate the diff when opening the page with two branches selected directly and just enable the calculate changes button when a branch is changed.

I did a first working prototype - please see attached screenshots.

Should I open a pull request for this or do you think this isn't a good idea?

Screenshots

Initial layout of the page (when opened with two branches the diff is displayed)

After a branch is changed the diff will be removed and just a short hint is displayed:

[a1012112796]

Hmm, maybe it's better to lazy load diff views like gh. which means user can click Create pull request button without waiting diff views loading.
/cc @silverwind @CirnoT

[CirnoT]

I believe lazy loading would be the only acceptable solution here, this is huge part of UI and hiding it behind user-interacatable button is something I'd rather not do.

[sebastian-sauer]

Loading the diff lazy sounds like a good alternative.

Maybe the manual diff calculation could reduce some server loads but the lazy loading feels more like the gh ui approach.

[jpraet]

This current automatic diff calculation is painful when you want to create a PR that does not target the master branch, e.g. for a backport to a release branch. A huge diff is calculated against the master branch first. And the "merge into" dropdown seems unresponsive until the page has completely finished loading.

[zeripath]

This current automatic diff calculation is painful when you want to create a PR that does not target the master branch, e.g. for a backport to a release branch. A huge diff is calculated against the master branch first. And the "merge into" dropdown seems unresponsive until the page has completely finished loading.

#16775 will stop this.

[MaxWaldorf]

Can anyone tell me if this is still in the roadmap or even implemented?

We are currently having issues because of the heavy quantity or diff in our repo...
Is there something we could do to reduce the wait time?

Cheers

[MaxWaldorf]

@sebastian-sauer

Did you do anything on your side in the end?

[MaxWaldorf]

@jpraet
Sorry to bug you but any idea if this will make it to any of the future releases?
Large repos are still suffering from that and I don't see any way to improve that...

Cheers

[jpraet]

In gitea 1.16 it eagerly loads the first MAX_GIT_DIFF_FILES (configurable in app.ini, defaults to 100), and has a "Show More" button to load the next 100 files. You could reduce the value of this parameter in your configuration.

[MaxWaldorf]

Thank you!

Will try that...

[MaxWaldorf]

@jpraet
Well actually when you create a PR it loads all commit diff which is the longest part...
Don't think this parameter can be changed (not seeing anything in the cheat sheet)

[hramrach]

Sounds like #6900