All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Petri Gynther <pgynther@google.com>
Cc: git@vger.kernel.org
Subject: Re: Feature request on git log --oneline <revision range> -- <path>...
Date: Wed, 13 Feb 2019 11:24:04 +0100	[thread overview]
Message-ID: <87k1i4j8aj.fsf@evledraar.gmail.com> (raw)
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.

  reply	other threads:[~2019-02-13 10:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13  4:57 Feature request on git log --oneline <revision range> -- <path> Petri Gynther
2019-02-13 10:24 ` Ævar Arnfjörð Bjarmason [this message]
2019-02-13 21:09   ` Junio C Hamano
2019-02-13 12:31 ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1i4j8aj.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pgynther@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.