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

4 messages from 2019-02-13 to 2019-02-13. Participants: Petri Gynther, Ævar Arnfjörð Bjarmason, Duy Nguyen, Junio C Hamano.
Thread: https://gitlist.dev/t/50487

## Petri Gynther, 2019-02-13 04:57

Subject: Feature request on git log --oneline <revision range> -- <path>...
Message-ID: <CAGXr9JHb1hjtMamdWt=oDg_eeBEuiDcbzAx+1XpV+HvvX1xsaA@mail.gmail.com>
URL: https://gitlist.dev/e/CAGXr9JHb1hjtMamdWt%3DoDg_eeBEuiDcbzAx%2B1XpV%2BHvvX1xsaA%40mail.gmail.com

```
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?

```

## Ævar Arnfjörð Bjarmason, 2019-02-13 10:24

Subject: Re: Feature request on git log --oneline <revision range> -- <path>...
Message-ID: <87k1i4j8aj.fsf@evledraar.gmail.com>
URL: https://gitlist.dev/e/87k1i4j8aj.fsf%40evledraar.gmail.com
In-Reply-To: <CAGXr9JHb1hjtMamdWt=oDg_eeBEuiDcbzAx+1XpV+HvvX1xsaA@mail.gmail.com>

```

On Wed, Feb 13 2019, Petri Gynther wrote:

> 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.

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.

> Is this an easy add-on to git log?

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.

```

## Duy Nguyen, 2019-02-13 12:31

Subject: Re: Feature request on git log --oneline <revision range> -- <path>...
Message-ID: <CACsJy8D2B_6yvBAQSeh3gvYHLOdfLmgiZ5Z=f4ZGeJ891X4Zjw@mail.gmail.com>
URL: https://gitlist.dev/e/CACsJy8D2B_6yvBAQSeh3gvYHLOdfLmgiZ5Z%3Df4ZGeJ891X4Zjw%40mail.gmail.com
In-Reply-To: <CAGXr9JHb1hjtMamdWt=oDg_eeBEuiDcbzAx+1XpV+HvvX1xsaA@mail.gmail.com>

```
On Wed, Feb 13, 2019 at 4:27 PM Petri Gynther <pgynther@google.com> wrote:
>
> 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?

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.
-- 
Duy

```

## Junio C Hamano, 2019-02-13 21:09

Subject: Re: Feature request on git log --oneline <revision range> -- <path>...
Message-ID: <xmqqmumzbdki.fsf@gitster-ct.c.googlers.com>
URL: https://gitlist.dev/e/xmqqmumzbdki.fsf%40gitster-ct.c.googlers.com
In-Reply-To: <87k1i4j8aj.fsf@evledraar.gmail.com>

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

> 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.

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.


```