git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

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