Re: git-rebase-walk

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

Hi Patrick,

> Date: 2026-10-02 08:46:36+0200
> From: Patrick Steinhardt <ps@pks.im>
>
[...]
> > 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]