Stefan Sperling <stsp@stsp.name> wrote:
> 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?

as an mblaze user myself, i really like the idea!

I agree with stsp thought, it doesn't _need_ to be bundled within got
itself (at least in the got(1) executable.)  I think it'd be best to
have it as a separate tool, maybe reusing the got internals to leverage
the privsep infrastructure and repository handling.

(and to fuel the brainstorm, instead of a separate "pick" and "scan"
primitives, which works great with mblaze given the domain but I'm not
sure would be useful for filtering commits, what about an awk-like
syntax of "pattern { action }" ?)

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

so... at least for the moment, what about syncinc tog and got
match_commit?  This way we have -S searching on the commit id itself,
author and committer.

diff 3ef807eedd4fec23cf457ea7cd55bc01407d57b9 /home/op/w/got
blob - 28ba9a46f202c773426d431a909c5dec6304d3ca
file + got/got.c
--- got/got.c
+++ got/got.c
@@ -3731,7 +3731,7 @@ get_datestr(time_t *time, char *datebuf)
 }
 
 static const struct got_error *
-match_logmsg(int *have_match, struct got_object_id *id,
+match_commit(int *have_match, struct got_object_id *id,
     struct got_commit_object *commit, regex_t *regex)
 {
 	const struct got_error *err = NULL;
@@ -3748,7 +3748,12 @@ match_logmsg(int *have_match, struct got_object_id *id
 	if (err)
 		goto done;
 
-	if (regexec(regex, logmsg, 1, &regmatch, 0) == 0)
+	if (regexec(regex, got_object_commit_get_author(commit), 1,
+	    &regmatch, 0) == 0 ||
+	    regexec(regex, got_object_commit_get_committer(commit), 1,
+	    &regmatch, 0) == 0 ||
+	    regexec(regex, id_str, 1, &regmatch, 0) == 0 ||
+	    regexec(regex, logmsg, 1, &regmatch, 0) == 0)
 		*have_match = 1;
 done:
 	free(id_str);
@@ -4067,7 +4072,7 @@ print_commits(struct got_object_id *root_id, struct go
 		}
 
 		if (search_pattern) {
-			err = match_logmsg(&have_match, id, commit, &regex);
+			err = match_commit(&have_match, id, commit, &regex);
 			if (err) {
 				got_object_commit_close(commit);
 				break;