Bug: git_bcommits does not display a file’s only commit

[k33nice]

RTFM Checklist

• I have searched exisiting issues / discussions
• I have read the Wiki including the Advanced section
• I have read man fzf / I am well versed in shell fzf

Operating system

Mac

Shell

zsh

Neovim version (nvim --version)

NVIM v0.11.1

Fzf version (fzf --version)

0.60.2

Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))

--bind alt-a:select-all,alt-k:preview-up,alt-j:preview-down

Is the problem reproducible with mini.sh?

• My issue is reproducible with mini.sh
• My issue IS NOT reproducible with mini.sh
• I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup({
})

Describe the bug / steps to reproduce

When running git_bcommits, any file with exactly one commit in its history does not display that commit in the list.

To Reproduce

1. In a new repo, create and commit a file:

   git init
   echo "hello world" > single.txt
   git add single.txt
   git commit -m "Initial add of single.txt"

2. Open single.txt

3. Run

:FzfLua git_bcommits

Expected behavior

git_bcommits should list all, including the very first (and only) commit.

Actual behavior

No entries are shown for files whose history contains a single commit.

This bug first appeared in commit c7b72ea (identified via git bisect).

[ibhagwan]

Can you run :FzfLua git_bcommits debug=1 and let me know the debug command output first line in the picker?

[k33nice]

Sure thing

[ibhagwan]

Ty, command seems ok, I’ll check what happened there.

[k33nice]

Not an expert, but my guess the problem is here c7b72ea#diff-785f9176c0a7771b4ee6c7cdd048630903408c5e736856a846ae56e9f67cc0e7R179

should be smth like

-  return ret, prev
+  -- flush the last line if it didn’t end with “\n”
+  if prev and #prev > 0 then
+    local line = trans and trans(prev) or prev
+    table.insert(ret, line)
+    prev = nil
+  end
+  return ret, prev

UPD: That patch works for me. Maybe a better way to do it, tho.

[ibhagwan]

UPD: That patch works for me. Maybe a better way to do it, tho.

Your patch is fine for this use case alone, when more than one data chunk arrives you can't assume prev is the last line of the stream.