From: Mark Jamsek <mark@jamsek.com>
Subject: Re: improve logmsg ref heuristics
To: Game of Trees <gameoftrees@openbsd.org>
Date: Sat, 28 Jan 2023 22:44:15 +1100

On 23-01-28 12:28PM, Stefan Sperling wrote:
> On Sat, Jan 28, 2023 at 10:17:57PM +1100, Mark Jamsek wrote:
> > The below diff fixes a case where we add an unrelated log message to the
> > preopulated editor.
> > 
> > If the user cherrypicked or backed-out a commit but also has unrelated
> > local changes in the work tree, and then specifies paths to 'got commit'
> > that are not in the set of paths that were changed in the cherrypicked
> > or backed-out commit, we should not add the log message of the bo/cy
> > commit.
> > 
> > This is fixed by checking if the path was indeed passed to 'got commit'.
> 
> Yes, ok, makes sense. We should only use the cherrypicked/backed-out
> log message templates if relevant paths are being committed.
> 
> And this commit won't be clearing these templates, right? And a
> future commit of an affected path would still use the template,
> as I would expect?

Yes, that's correct. So, in the above case, there will be no
prepopulated log message. The cherrypicked/backed-out changes remain in
the work tree and the logmsg ref also remains in refs/got/worktree, so
if the next commit includes those changed paths (e.g., the user just
runs 'got commit' without specifying any paths or specifies at least one
of the affected paths), the editor will be populated with the log
message of the cherrypicked/backed-out commit.

> There will be edge cases where a cherrypick affects multiple paths
> and the user chooses to only commit one of them. In that case, I would
> expect the log message template to be used during this initial commit
> of some affected path, and then removed. This would leave changes on
> other affected paths without a log message template.

That's correct. We might be able to improve the logmsg ref removal
heuristic so that the template remains; if you like I can look at doing
that?

> This is a consequence of the design decisions we've made, where changes
> are tracked per-path, rather than as content diffs. I think this is
> acceptable as long as users are made aware of this limitation.
> The man page should mention this somewhere. I will try to remember this
> when I get a chance to look over the relevant bits of documentation again
> and perhaps adjust them a bit.
> 

-- 
Mark Jamsek <fnc.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68