Re: Newbie contribution idea for 'git log --children': input requested

From: Jacob Stopak <jacob@initialcommit.io>
Date: Sep 18, 2022, 03:19 UTC
Message-ID: <YyaOJa1FNyWK+M4U.jacob@initialcommit.io>
In-Reply-To: <YyKzOk5AQBz1pmAh@coredump.intra.peff.net>

On Thu, Sep 15, 2022 at 12:08:10AM -0500, Jeff King wrote:

Show 9 quoted lines

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

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.

(I guess this would rely on the user knowing what the option format is for their pager, which isn't ideal... but I assume that it's not great practice to have git store option formats for external tools like pagers since they could change over time and then there is the can of worms of which pagers git would even support this feature for - although it does seem git stores default flags for LESS and LV).

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.
 
But I don't think I saw an existing way to pass in dynamic parameters, such as a
commit id, into the pager environment. This ability could potentially be useful
for setting other dynamic pager options as well, which can currently only be
done by stuff like repiping git log's output as in your example.

From what I can tell only static content like flags appear to be able to be set in the current pager environment, but maybe I'm missing something obvious...

It would be great to get your thoughts.

-Jack