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