file name commit message helper

[axet]

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

When being lazy I usually do not put full file name in front of commit message. That causing a bad looking commit history which makes it hardly readable.

Describe the solution you'd like

Lazzines caused me beg you adding a button to commit message dialog which add currently changed file / filenames to commit message.

Describe alternatives you've considered

Being lazy and wait for someone to do so.

Additional context

git log may look like this:

'file1 adding comments'
'file2 adding new executable, fixing bug1'

Some commit policy may include file / package name in front of commit message to make it clear what happened in the changes.

[mark2185]

Shouldn't it be obvious from the commit message which file the message is reffering to? If it's only a handful files, of course.

If you do have a lot of files, I'd suggest using an external commit editor (C) with the git.commit.verbose flag set and using a macro/helper there.

[axet]

Not sure I understand the question. Lets say I did few cleanups in file 'textures.c' and commit message would be "cleanups". Isn't that worse that having "textures.c cleanups" - meaning no changes just code cleanups, reformatting?

[mark2185]

Well I don't see a reason for putting the name of the file in the commit message when I can look at the list of files in that commit, but that's just user preference.

Here's an example from lazygit itself:

You can see that the "refactor" mentioned in the commit message obviously refers to main_branches.go and slice.go. The commit message describes what was done, the list of files describes where the change took place.

But as I said, personal preference.

[axet]

commit subject

must have a prefix that depends from what you are doing in the commit

kernel: for kernel and kmod (kernel module) packages
package name: for packages
device architecture: for devices (for example, mvebu: or ramips: add support to example_eval board )
tool name: for tools
build: for general buildsystem changes that are not targeted at something in /toolchain

https://openwrt.org/submitting-patches

Double checked, it isn't just my imagination. Having filename (package, kernel, etc) prefixed to commit, could be a policy, since it is more clear and easier to navigate thorough commit history over than just commit message.

[stefanhaller]

I'm with Luka here, I don't think it's useful to put filenames in commit messages, and we are not going to add a feature that makes this easy. Yes, in some projects it might be a convention to add package names to commit messages (or maybe project names or library names, especially in a monorepo), but those are very often not the same as filenames, and there's no way for lazygit to guess which of a file's parent directories is the package name.

Lets say I did few cleanups in file 'textures.c' and commit message would be "cleanups". Isn't that worse that having "textures.c cleanups"

No; "Clean up whitespace" or "Fix indentation" or "Clean up formatting" are all perfectly fine commit messages for such a case. If your readers want to see which files are affected, they can easily see this from the diff.

'file2 adding new executable, fixing bug1'

This is an interesting example that seems to indicate that thinking about file names too much encourages you to group changes by the wrong criterion. You are putting these two changes in the same commit just because they affect the same file; those should be two separate commits.

[axet]

If your readers want to see which files are affected, they can easily see this from the diff.

That is waaay off that you could expect from project named lazy git!