Re: git-rebase-walk

From: Alejandro Colomar <alx@kernel.org>
Date: Oct 2, 2026, 07:19 UTC
Message-ID: <ar9ZRrVyr1-Fk2LZ@debian>
In-Reply-To: <ar9TTB5nmPPAdABE@pks.im>

Hi Patrick,

> Date: 2026-10-02 08:46:36+0200
> From: Patrick Steinhardt <ps@pks.im>
>

[...]

Show 7 quoted lines

> > My script I use it in shadow-utils and in the Linux man-pages project,
> > and is in use today.  I was wondering if there was interest in
> > integrating it to git(1). 
> 
> I guess the answer is "maybe". The fact that multiple folks have solved
> similar issues over the course of many years is an indicator that the
> funcitonality may be more generally useful.

Nice.  :)

> But it probably shouldn't be
> a separate script, so if we wanted to integrate it I'd think the best
> way forward would be to integrate it into git-rebase(1) directly.

For a git-rebase(1) option, I guess it would have to be named something like --first-conflict. --first conflict because it doesn't really rebase on the target commit, but rather on the first commit of that branch which causes conflict.

> That's of course more involved though, so I understand in case you're
> not interested in doing that.

I'd still be interested, but it may take me time, and I'll probably need help.

Show 8 quoted lines

> > If not, I will likely provide it in the man-pages repository as a help
> > tool (which might end up packed by distros as part of manpages-utils).
> > Is that okay to you?  (I ask mainly because it's using the git-
> > namespace for commands, so you should at lease be aware of it.)
> 
> I mean overall this is our primary way of extension, by picking up
> utilities that have the "git-" prefix. So arguably you don't have to ask
> us for permission to do that.

I think I'll do this to provide the command in the meantime as an easy extension, with the goal of deprecating it eventually once it lands in git-rebase(1).

> Whether it makes sense to distribute such a tool as part of
> manpages-utils is a different question, and one where I myself am of a
> split mind. But that feels more like a question for distributors rather
> than for us in the Git project.

We already have other tools that are generally useful, such as grepc(1), which finds C source code with a grep(1)-like interface. It's essentially similar to things like ctags, but it has a traditional command-line interface, and doesn't use any index or cache (yet it's very fast).

So, it wouldn't hurt having this one.

Have a lovely day! Alex

> 
> Thanks!
> 
> Patrick

-- 
<https://www.alejandro-colomar.es>