From: Jeff King <peff@peff.net>
To: Jacob Stopak <jacob@initialcommit.io>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Newbie contribution idea for 'git log --children': input requested
Date: Tue, 20 Sep 2022 18:28:24 -0400 [thread overview]
Message-ID: <Yyo+iBNF1bydcQt+@coredump.intra.peff.net> (raw)
In-Reply-To: <YyaOJa1FNyWK+M4U.jacob@initialcommit.io>
On Sat, Sep 17, 2022 at 08:19:01PM -0700, Jacob Stopak wrote:
> On Thu, Sep 15, 2022 at 12:08:10AM -0500, Jeff King wrote:
> >
> > I usually solve this by doing a single traversal, and asking the pager
> > to jump straight to the commit of interest, at which point I can scroll
> > up and down to see the context. Like:
> >
> > git log --color | less +/$some_old_commit
> >
> > I'm not 100% sure I understand the original use case. But if I do, and
> > that solves it, I wonder if we could make it more ergonomic somehow.
>
> Great points thanks for the details. I do think your method addresses the use
> case I was trying to describe, which is being able to quickly see context in
> both directions when you jump to a commit far from any branch/tag.
One thing my suggestion doesn't help with is when $some_old_commit is
the current HEAD. Something like:
git checkout HEAD~50
git log --magically-start-at=HEAD
wouldn't work, because to get context you need to start traversing from
somewhere else. So really you want to start with "--branches --tags", or
maybe even "--all" as traversal points, and then show whatever commit
(be it HEAD or something else) in context.
> But like you implied, it would be nice to be able to do it with a real command
> line option to git log instead of repiping into less, something like:
>
> git log --scroll-to=commit_id
>
> I peeked into builtin/log.c and saw how it calls setup_pager(); at the end of
> cmd_log_init_finish(...). I have a basic understanding now of how the default
> pager and pager environment are roped in.
>
> One obvious issue is that different pagers might have different ways (or no way
> at all) to auto-scroll to a pattern. But this might be solved by allowing the
> user to add their pager option such as +/ to the pager environment, which would
> only be applied when the user adds the --scroll-to=commit_id option to git log.
Yes, exactly. It's awkward to assume too much about the pager, because
it could be literally anything. I think the worst thing we can do is
stick extra bits on the command-line like this, because it may actually
break other pagers. As you noted, we do have a default LESS variable,
which is OK, because at worst it is simply ignored.
I think we _could_ append "+/whatever" into $LESS, and that would work.
It feels kind of dirty somehow, though.
> Anyway, then the commit_id would be dynamically added after, probably in a format like
> "commit <commit_id>" so that the same pattern in commit messages doesn't match.
Right, and you can anchor it with "+/^commit ...". But of course that
depends on the output format. Something like "--oneline" would have a
partial commit. If done inside Git, it would know the format it will
use. But if you don't mind being a little sloppy, you can probably write
a regex which works well enough.
Taking it all together, a script like this works:
-- >8 --
#!/bin/sh
focus=$1; shift
# use --short rather than --verify so we match --oneline
short=$(git rev-parse --short "$focus") || exit 1
# this regex tries to match a variety of formats:
#
# - anchor to the left to avoid false positives
# - make "commit" optional to catch both regular and oneline
# - skip --graph markers
# - we can ignore colors; less skips ANSI codes when matching
regex='^[*|\\ ]*(commit )?'
# yuck, there's no way to ask "which pager would you use for git-log".
# Stuffing the value inside $LESS works, but if we override Git's
# internal value, then we have to recreate it.
LESS="${LESS-FRX} +/$regex$short"
export LESS
exec git log --branches --tags "$@"
-- >8 --
Saving that as git-focus and setting the execute bit lets you do stuff
like:
git checkout HEAD~50
git focus HEAD
I think this could be done inside Git, though it would be a little
awkward. Maybe it's worth living with that script for a while and seeing
if you like it.
-Peff
next prev parent reply other threads:[~2022-09-20 22:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-11 23:09 Newbie contribution idea for 'git log --children': input requested Jacob Stopak
2022-09-12 0:41 ` Junio C Hamano
2022-09-15 5:08 ` Jeff King
2022-09-15 17:08 ` Junio C Hamano
2022-09-18 3:19 ` Jacob Stopak
2022-09-20 22:28 ` Jeff King [this message]
2022-09-21 0:24 ` Jacob Stopak
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yyo+iBNF1bydcQt+@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jacob@initialcommit.io \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).