On Sat, Jun 11, 2022 at 01:55:42PM -0700, Evan Silberman wrote:
> > The main goal of -S is to support interactive search.
> > For scripting one could use Git, or parse the output of 'got cat',
> > or parse 'got log | grep ^from:', or write a custom Got frontend in C
> > which reads the desired data from commit objects in code.
> 
> I had the brainstorm while walking home that the pattern used by Leah Neukirchen’s mblaze tools might make sense for picking out commits. With mblaze, you filter a set of emails out of your Maildir with mlist, magrep, and mpick, and then you do something with them, with mscan and mshow being sort of analogous to one-line and full log messages. The data piped between utilities is generally just the path to an email; the got analogue would presumably be a commit sha. So you can imagine a design like:
> 
> `got pick -F 'author == "evan@jklol.net" && patch ~ "got_log\w+"' | got scan`
> 
> One of the things got is doing well at is having orthogonal commands. log is traditional but picking commits from history and displaying information about a commit look like orthogonal operations when you scratch at them. Too radical? Or promising?

This does reach beyond the intended scope of Got. The UI should primarily
support use cases required for OpenBSD development in a simple and
straightforward way, instead of being highly flexible.
There may be external use cases which map well onto the established UI design,
and we can consider adding support for them, but only if the extra maintenance
cost is relatively low.

What you suggest above does not cover a use case which must be covered
for OpenBSD development. And it goes beyond the UI concepts which are
already in use. And it would probably require a non-trivial amount of
code to be added.

I don't dislike your idea, but I think a separate tool would be a better
place for it. One reason for reusing the Git repository format was to
allow use of other tools, which support the same format, alongside Got.