Re: [PATCH] gitk: add user-defined custom commands

On Sun, 2026-08-09 at 10:33 +0200, Johannes Sixt wrote:
> Am 07.08.26 um 23:39 schrieb Tim Wiederhake:
> > If I had proposed a patch to this effect, I am sure it would have
> > been
> > nack'd as too niche, wrong tool, or any other reason. But having
> > the
> > possibility to define custom commands allows users to adapt gitk to
> > their workflow instead of the other way round. I am very open to
> > suggestions on how to put this in the commit message without
> > resorting
> > to (contrieved) examples.
> 
> The reason why you were unable to sell the change better is that your
> change is a large set of features in a single commit. If you started
> small, it would be much easier to get off the ground.
> 
> For example, start with "I notice in the diff that a change is not
> quite
> right. Let me start an editor with the file loaded." That is a
> feature I
> can understand is useful.
> 
> Next, let the editor start with the cursor at a particular line!
> That's
> quite useful, too, but need not be part of the first step.
> 
> Then proceed to a use-case that needs to call `git rebase`.
> 
> But when it comes to author, committer, dates, or blame information
> as
> potential substitutions, you will have a much harder time to argue
> that
> they are useful. Move these features in their own patch. If you do
> have
> a use-case, mention it.
> 
> The gist of it is: make this a patch series that starts small and
> works
> its way forward with additional features in new commits. Don't add
> features just "because we can".
> 
> > Regarding the use about AI: I used Claude to produce the initial
> > implementation. I do not write Tcl, and frankly, this patch has not
> > changed that. I have reworked the code - using Claude - until it
> > was
> > effectively the Tcl version of code I would have written myself in
> > Python or C or any other language that I actually understand. Does
> > that
> > pass the bar?
> 
> I am not 100% sure. I take it that you understand what the added Tcl
> code does (that should not bee too difficult even if this is your
> first
> time doing Tcl). However, the Git project's guideline says:
> 
> > It’s not yet clear that this can be legally satisfied when 
> > submitting significant amount of content that has been generated by
> > AI tools.
> So,... Any advice from the Git community would be appreciated.
> 
> -- Hannes

Thanks for the continued feedback.

I think there may be a misunderstanding about what this patch does. I
am not proposing "add an edit-file button to gitk." I am proposing "let
users add their own commands to the context menus." The rebase+edit
workflow was an example of what becomes possible. It is not the feature
itself.

The incremental approach you suggest (first add an editor launch, then
line numbers, then rebase support) would make sense if I were proposing
a specific built-in workflow. But I am proposing a generic mechanism.
Shipping it with only %f but not %i or %t would produce a half-useful
extension system that nobody can actually use, existing only to satisfy
the review process. The individual substitutions are not independent
features; they are parameters of a single feature.

I did give a rationale: enabling users to adapt gitk to their workflow
instead of the other way around. And I did give a concrete example.
"Don't add features just because we can" does not apply here. The
feature has a stated purpose and a demonstrated use case. If the
rationale is unconvincing, I am happy to hear what would be convincing,
but I would rather not have to justify each placeholder individually.

That said, if splitting the patch into smaller pieces makes review
easier, I can do that -- as long as we agree that the goal is the
complete mechanism, not a series of standalone features that each need
to justify their own existence.

Regarding the use of AI: I designed the feature. The UI layout, the
"data model", the substitution mechanism, the execution semantics...
and described it in English in form of a prompt. An AI translated that
description to Tcl. I then reworked the output through multiple
iterations until the code matched what I would have written myself in a
language I'm proficient in. I believe this is a valid use of AI. The
algorithm and design are mine; the language-specific syntax is not, and
I don't think it needs to be. AI guidelines exist to guard against
unreviewed, ununderstood code being dumped into the project (and I very
much agree with that). But that is not what happened here.

Regards,
Tim