Feature request on git log --oneline <revision range> -- <path>...

git developers:

Small feature request on: git log --oneline <revision range> -- <path>...

Could we add an option to:
1) display all commits in <revision range> unconditionally
2) use a special marker (e.g. star) for commits that touch <path>...
and list the files from <path>... that this commit modified

Sample output: git log --oneline (--annotated?) HEAD~5..HEAD -- Makefile kernel/printk/printk.c

  aaaabbbbccc1 uninteresting commit 1
* aaaabbbbccc2 fix Makefile
    Makefile
  aaaabbbbccc3 uninteresting commit 2
* aaaabbbbccc4 fix Makefile and printk()
    Makefile
    kernel/printk/printk.c
  aaaabbbbccc5 uninteresting commit 3

In other words:
- commits that don't touch <path>... are still listed (without special markers)
- commits that touch <path>... are listed with * prefix, and the files
from <path>... that the commit modified are listed below the commit

This is very useful for kernel LTS merges, when we want to know which LTS patches in the merge chain actually touched the files that matter for a specific build target.

Is this an easy add-on to git log?

On Wed, Feb 13 2019, Petri Gynther wrote:

What do you think such an option should do when it finds negative path specs, e.g. this on git.git:

    git log --oneline --stat -- ':!/Makefile' '*Makefile*'

Should it only render positive matches, or distinguish between matched/blacklisted/not-matched, your example (with no negative patspecs) just shows matched/not-matched.

It's been a while since I looked at this code, but (depending on the answer to the above) I don't think it would be that hard. We already pass up what we matched for the --stat machinery. E.g. try on git.git:

    git log --oneline -1 --stat 32ceace39f --
    git log --oneline -1 --stat 32ceace39f -- '*fetch.c'

The former shows a few modified *.c files in the --stat, the latter just builtin/fetch.c since it matched.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Another thing to consider is what this would do to the merge simplification.

If I understand it correctly, this is sort-of like a reverse of the "--full-diff" option, where the pathspec *is* used to limit and simplify the history, but for the purpose of displaying "log -p" output, the pathspec is widened to show the entire change. This instead makes the traversal ignore the pathspec and uses it only to limit the "log -p" output. I do not think I would be fundamentally opposed to a feature like this.

On Wed, Feb 13, 2019 at 4:27 PM Petri Gynther <pgynther@google.com> wrote:

Adding the "*" is not that hard, I think. The hard part is UI. Soon somebody may want to "list commits touching sub/ then add "*" on ones that touch sub/dir/". Meanwhile I think you can still achieve that with a bit of scripting and processing "git log --raw --oneline <revisions>" output.