File quick history shows many irrelevant merge commits

[ian-h-chamberlain]

GitLens Version

v12.1.2

VS Code Version

Version: 1.69.2 Commit: 3b889b090b5ad5793f524b5d1d39fda662b96a2a Date: 2022-07-18T16:12:57.074Z Electron: 18.3.5 Chromium: 100.0.4896.160 Node.js: 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin x64 21.5.0

Git Version

git version 2.37.0

Description

There appears to be a regression from #259 – I am not sure in what version the behavior changed, but I am once again seeing lots of irrelevant merge commits in the "quick file history".

This is my Gitlens-related config:

Details

{
    "gitlens.advanced.fileHistoryFollowsRenames": true,
    "gitlens.advanced.messages": {
        "suppressCommitHasNoPreviousCommitWarning": false,
        "suppressCommitNotFoundWarning": false,
        "suppressFileNotUnderSourceControlWarning": false,
        "suppressGitVersionWarning": false,
        "suppressLineUncommittedWarning": false,
        "suppressNoRepositoryWarning": false,
    },
    "gitlens.blame.avatars": false,
    "gitlens.blame.highlight.locations": [
        "gutter",
        "line",
        "overview"
    ],
    "gitlens.codeLens.authors.enabled": false,
    "gitlens.codeLens.enabled": false,
    "gitlens.codeLens.recentChange.enabled": false,
    "gitlens.currentLine.enabled": true,
    "gitlens.hovers.currentLine.enabled": true,
    "gitlens.hovers.currentLine.over": "annotation",
    "gitlens.keymap": "alternate",
    "gitlens.menus": {
        "editor": {
            "blame": true,
            "clipboard": true,
            "compare": true,
            "details": true,
            "history": true,
            "remote": true,
        },
        "editorGroup": {
            "blame": true,
            "compare": true,
        },
        "editorTab": {
            "clipboard": true,
            "compare": true,
            "history": true,
            "remote": true,
        },
        "explorer": {
            "clipboard": true,
            "compare": true,
            "history": true,
            "remote": true,
        },
        "scmGroup": {
            "compare": true,
            "openClose": true,
            "stash": true,
            "stashInline": true,
        },
        "scmItem": {
            "clipboard": true,
            "compare": true,
            "history": true,
            "remote": true,
            "stash": true,
        }
    },
    "gitlens.mode.active": "review",
    "gitlens.mode.statusBar.enabled": false,
    "gitlens.plusFeatures.enabled": false,
    "gitlens.statusBar.enabled": false,
    "gitlens.views.repositories.autoRefresh": false,
}

Toggling gitlens.advanced.fileHistoryFollowsRenames, as described in that issue, seems to have no effect.

Logs, Screenshots, Screen Captures, etc

The git command that appears to be running, when I turned on debug logging, for fileHistoryFollowsRenames false (reformatted for readability):

 git log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cn%x3e%x20%cN%n%x3cm%x3e%x20%cE%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e \
	-n201 -m --numstat --summary $branch -- go.mod 

And, for fileHistoryFollowsRenames = true:

git log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cn%x3e%x20%cN%n%x3cm%x3e%x20%cE%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e \
	-n201 --follow --first-parent -m --numstat --summary $branch -- go.mod 

As mentioned in this comment (https://github.com/gitkraken/vscode-gitlens/issues/259#issuecomment-394871856), the -m --first-parent seems to be part of the problem here. I get the best output (closest to what I would like in the file history view) when I run (with or without --follow):

git log -n7 --follow  --oneline --summary $branch -- go.mod

Maybe it would makes sense to have a configuration value for whether -m is used at all in the command?

[JamesHutchisonCarta]

I'm seeing the same issue. On top of this, the actual merge commit that contains the change in question shows no changes in the diff UI. All the ones that happened to do a merge with the main branch after it was committed show the change in question. The cause could potentially be the use of squash and merge

Workaround seems to be to use timeline in the explorer view

Changing follow renames doesn't fix the problem for me.

[JamesHutchisonCarta]

Just tried this with follow renames enabled, which allows branch filtering, and it looks better. Essentially everything is unusable except Follow renames: On and Toggle Filter: Only current branch

Also, the branch filter is disabled at first, but after you enable toggle renames it becomes active and stays active.

[ian-h-chamberlain]

@JamesHutchisonCarta am I correct in thinking that these are the settings you are using?

{
    "gitlens.advanced.fileHistoryFollowsRenames": true,
    "gitlens.advanced.fileHistoryShowAllBranches": false,
}

When I have those settings, all I see are merge commits in the file history / "quick file history" views...

You mentioned "squash and merge", perhaps those settings work in that case but not for plain merges?

[psergei]

Any plans to fix this issue? It is pretty annoying as I'm seeing lots of records in GitLens File History like Merge remote-tracking branch 'origin/master' into ...

and there seems to be no way to hide them.

[lucascosti]

👋 Not sure if it's related, but our repos also use a squash and merge strategy for merging into the default branch, and I'm also seeing this issue. The timeline view is a great workaround for the time-being, but it would be great to get this fixed.

[jenseralmeida]

This is such an important use case. Is there any chance we can get this a top priority?

[jaklan]

One more bump, file history is simply unusable at the current state 😕

[jonathan-codebase]

Another bump. I've found myself searching for a fix every few months for the past year+

[domsieb]

One more bump. I have the same issues and I would be quite happy if this would be fixed rather sooner than later 😊

[dan-dr]

Same here

[jenseralmeida]

Do not take me wrong, as I am just happy to see this being considered for a version.

However, I would call it a bug instead of a feature, as this worked just fine before. So, we had a nice feature which is a file history integrated with everything else on GitLens, and now I did need to stop to use as it is useless after breaking (being polluted with useless merge entries), and I am using the less featured default vs code timeline.

So, in the end, it is not important for me to call it a bug or a feature, but I would love to have it back as it is taking a long time to have this fixed, back to what it was before.

[dreamingblackcat]

Same issue here. I agree with @jenseralmeida 's comment.

This is an important feature that's currently broken.

[prestto]

Also getting this issue

[hansu]

An interesting fact is that it works perfectly on my old Ubunto 18 Gnome machine, but not under Debian Bookworm. Both the same VScode and GitLens versions (1.77.0 and 13.4.0).

Ubuntu 18 / Debian Buster:

Debian Bookworm:

[sobolevsv]

same issue GitLens — v13.5.0 Version: 1.77.3 (user setup) Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710 Date: 2023-04-12T09:16:02.548Z Electron: 19.1.11 Chromium: 102.0.5005.196 Node.js: 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0.19045 Sandboxed: Yes

[hendiko]

I've been struggling with this issue for a while, how to fix it?

[Spongman]

just noting that this issue has more upvotes than every issue that was fixed in 13.5, 13.4 & 13.3 ...

also, this is clearly a usability issue (ie. bug), not a feature request. and as, such, it's the most up-voted unresolved bug in the issues list.

[arv47x]

Same here.

Gilents: v14.0.1

VScode Version: 1.79.2 (Universal) Commit: 695af097c7bd098fbf017ce3ac85e09bbc5dda06 Date: 2023-06-14T08:58:52.392Z Electron: 22.5.7 Chromium: 108.0.5359.215 Node.js: 16.17.1 V8: 10.8.168.25-electron.0 OS: Darwin x64 22.5.0

[suzmas]

This just started happening to me within the last week - it really sucks because I used File History heavily and now it's useless.

[eamodio]

I've defaulted the File History view to follow renames. I've also removed merge commits from the File History view by default, and added a [Show|Hide] Merge Commits toggle to the view's ... menu and a corresponding gitlens.advanced.fileHistoryShowMergeCommits setting to specify whether merge commits will be show in file histories.

Can you please verify this fix in tomorrow's (v2023.10.07xx) pre-release edition of GitLens? Thank you so much!

You can switch to the pre-release edition of GitLens, by clicking on the "Switch to Pre-Release version of this extension" from the Extensions view.

[psergei]

Works for me, thank you!

[hansu]

Works for me too, thank you!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.