On Tue, May 13, 2025 at 12:13:30AM +0000, brian m. carlson wrote: > > 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. > > > - 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. > 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
