Re: Cleaning up "contrib/"

From: Jeff King <peff@peff.net>
Date: May 14, 2025, 18:19 UTC
Message-ID: <20250514181938.GC2196784@coredump.intra.peff.net>
In-Reply-To: <aCKOqs52TDZDvAXJ@tapette.crustytoothpaste.net>

On Tue, May 13, 2025 at 12:13:30AM +0000, brian m. carlson wrote:

Show 8 quoted lines

> > I think diff-highlight is something that _should_ eventually happen
> > inside git-diff itself (because it would be more efficient and we could
> > do a better job). But it wouldn't share any implementation with what's
> > in contrib/.
> 
> I think there are definitely users of diff-highlight.  I remember seeing
> a reference to it recently and not realizing it was in contrib, but it
> is actually used by others.  I don't use it myself, though.

Oh, there definitely are users. Sometimes they contact me outside the list. ;) I thought the discussion around contrib/ here was more around "should things in contrib/ spin out to their own projects", and not "should they be removed and forgotten". :)

I am perfectly happy if these things stay in contrib/ forever. I was only voicing that I'd be OK taking them on as outside projects if we didn't want to keep them in-tree anymore.

Show 15 quoted lines

> > >   - Credential helpers.
> > 
> > These ones are tricky. In theory they could be spun off into their own
> > projects, and we already have examples in the wild of things like GCM
> > which are maintained totally separately.
> > 
> > But I think we may need to find people to step up as maintainers. In
> > particular, I think osxkeychain is probably used by a lot of people, and
> > probably shouldn't just go away. But I don't know how the maintainer
> > would be. I wrote it originally, but don't (and never did) use it
> > myself, or even have access to a macOS machine.
> 
> These are often shipped by distributors.  Apple ships osxkeychain, as
> does Homebrew.  Many Linux distros ship libsecret and it's the
> recommended choice for desktop Linux.

Right, I know people use them. What I meant was that if we wanted to spin them to out-of-tree projects, we'd need somebody to volunteer to be the maintainer of those projects. If they stay in-tree we can be a bit looser (your "I don't want to be _the_ maintainer, but I can contribute").

It does put more load on Junio, though. E.g., if there is a security problem the project has to deal with embargoed release engineering, whereas a separate project would do its own releases.

Show 6 quoted lines

> wincred, while not super popular, is still used and is smaller and
> lighter than GCM.  It doesn't actually look like GCM is seeing a great
> deal of maintenance either at this point, so I'd say they're about
> equally well maintained.  Since I don't use Windows, I don't know if
> there are other usecases (such as noninteractive uses) that are better
> supported by wincred, but I'd recommend keeping it.

I don't use Windows, so I don't have a personal opinion. Code may not see updates because it mostly works, or because hardly anybody is using it. Or people may be using it but it's still broken. ;)

Last time wincred had a security hole (in 2020), the phrase "unsafe and unmaintained" was thrown about on the security list, but we ultimately fixed at least the immediate issue. But I find its general matching strategy to be not very confidence-inspiring.

Dscho (or anybody else familiar with Windows) may want to comment further.

-Peff