Improved or configurable behavior for PrevMessage

[creinig]

Is your feature request related to a problem? Please describe.

In the commit dialog, the "PrevMessage" and "NextMessage" bindings get the messages from git log --reflog ..., which includes commit messages from all branches. With > 40 developers working on about the same number of feature branches, that means the message I get from the "PrevMessage" binding is effectively random.

I need to include the issue ID of my feature branch in the commit message, so I'd like to pre-fill the commit message with my previous one from my branch.

Describe the solution you'd like

When fetching commit messages via git log, use --walk-reflogs instead of --reflog

Describe alternatives you've considered

I personally consider the current behavior a bug, but others might like it. So maybe this should be configurable?

[CKolkey]

I'd look at a PR if you have a suggestion on improving it :)

[creinig]

@CKolkey : Well, it depends a bit on the desired behavior.

My initial suggestion was to use --walk-reflogs instead of --reflog in log.lua:555:

function M.reflog_message(skip)
  return git.cli.log
    .format("%B")
    .max_count(1)
    .args("--walk-reflogs", "--no-merges", "--skip=" .. tostring(skip))
    .call({ ignore_error = true }).stdout
end

But after playing a bit with it I actually prefer removing the --reflog altogether and just take the messages from the plain log:

function M.reflog_message(skip)
  return git.cli.log
    .format("%B")
    .max_count(1)
    .args("--no-merges", "--skip=" .. tostring(skip))
    .call({ ignore_error = true }).stdout
end

(Edit: Of course the method would have to be renamed as well etc)

Reason: the --walk-reflogs variant sometimes only returns way too few entries (e.g. after a fresh clone). And I don't see any downside to use the plain log. Do you know why the --reflog variant was chosen initially?