From: Stefan Sperling Subject: Re: Bug in got log commit modifier handling? To: Timo Myyrä Cc: gameoftrees@openbsd.org Date: Wed, 24 Sep 2025 21:13:37 +0200 On Wed, Sep 24, 2025 at 09:22:10PM +0300, Timo Myyrä wrote: > Ah, good explanation but I had to run few more iterations with got log > to get hang of it. > > So the command "got log -s -c bbdf152:+ -l 1 Makefile" starts the > iteration one commit before bbdf152, and filters the commits by the > path. What commits are left in these is finally limited to first match > by the "-l 1" option. Also keep in mind that the path filter accepts multiple paths. In the general case, each file named on the command line could have a different "last-modified" revision. So if the 'got log' syntax were working as you were trying to use it, the resulting behaviour would not be well defined for the case where multiple paths are specified. > Not sure is there a way for "got log" to efficiently get the > next/previous commit to given file based on a commit. Currently it seems > only option is to query the full history with "got log -s > editors/emacs/Makefile" and then filtering the full set of commits by > the id to get the previous and next commits by file. Yeah, I don't see an easier way to represent the request you want to make. You would need to run 'got log' and filter the output. And maybe use the -R option in case it helps to have commits listed in reverse order. For non-scripting purposes you could alternatively run 'tog log path' to see a listing that looks like got log -s and offers interactive behaviour. For my taste, the got log command is complex enough as it is. I don't see a big problem with having to do some post-processing on the output of commands to obtain more specific information. We are mostly trying to model our UI with getopt() only. The :+1 syntax is a rare exception to this. This is purpusefully kept simple but we cannot expect this approach to cover complex queries of the nature seen in the git CLI or the hg CLI (which even offers a mini-query language that operates on arbitrary sets of revisions).