git svn clone failed

git svn clone failed

[BERENDSEN Arnoud]

What did you do before the bug happened? (Steps to reproduce your issue)

- I was migrating an SVN repository to Git using:
git svn clone <my-svn-repo> --stdlayout --authors-file=C:\path\to\my-authors-file.txt  --preserve-empty-dirs .


What did you expect to happen? (Expected behavior)

- I expect the entire process to succeed without errors.
When unavoidable errors do happen, I expect the error message to be helpful, give a clear description of what the underlying problem is, and how to solve it.


What happened instead? (Actual behavior)

- The migration failed with the folowwing error:

r2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)
Found possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814
W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
expected path: branches/trunk
    real path: trunk
Continuing ahead with trunk
W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
expected path: branches/trunk
    real path: trunk
Continuing ahead with trunk
Initializing parent: refs/remotes/origin/<my-branch-name>@2814
Use of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.
Use of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.
fatal: Not a valid object name
ls-tree -z --name-only  data/OVK/: command returned error: 128




What's different between what you expected and what actually happened?

- The process failed instead of succeeding, and the error was incredibly unhelpful, and seems like a bug in Git.pm.


Anything else you want to add:


Before this happened, another error happened first, which may or may not be related:

r1126 = 9d5f073cfcac00b9d8586923da4d045699244749 (refs/remotes/origin/trunk)
Failed to strip path 'src/Lijsten/.gitignore' ((?^:^trunk(/|$)))

This also is not a very helpful error, as it gives no indication of *why* it failed to 'strip the path' (strip it of what, anyway?), nor why it failed on this particular commit.

Restarting the process by rerunning the same 'git svn clone' command seemed to 'fix' the problem by just continuing the process (which begs the question why the process aborted itself in the first place. Couldn't it just have continued?)



Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.49.0.windows.1
cpu: x86_64
built from commit: cca1f38702730b35f52c29efd62864b85e85ddcc
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.12.1
OpenSSL: OpenSSL 3.2.4 11 Feb 2025
zlib: 1.3.1
uname: Windows 10.0 22631
compiler info: gnuc: 14.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]

C2 - Restricted use

Re: git svn clone failed

[Johannes Schindelin]

Hi Arnoud,

On Fri, 2 May 2025, BERENDSEN Arnoud wrote:

> What did you do before the bug happened? (Steps to reproduce your issue)
> 
> - I was migrating an SVN repository to Git using:
> git svn clone <my-svn-repo> --stdlayout --authors-file=C:\path\to\my-authors-file.txt  --preserve-empty-dirs .
> 
> 
> What did you expect to happen? (Expected behavior)
> 
> - I expect the entire process to succeed without errors.
> When unavoidable errors do happen, I expect the error message to be helpful, give a clear description of what the underlying problem is, and how to solve it.
> 
> 
> What happened instead? (Actual behavior)
> 
> - The migration failed with the folowwing error:
> 
> r2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)
> Found possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814
> W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
> expected path: branches/trunk
>     real path: trunk
> Continuing ahead with trunk
> W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
> expected path: branches/trunk
>     real path: trunk
> Continuing ahead with trunk
> Initializing parent: refs/remotes/origin/<my-branch-name>@2814
> Use of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.
> Use of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.
> fatal: Not a valid object name
> ls-tree -z --name-only  data/OVK/: command returned error: 128

In Git for Windows, `git svn` is quite a maintenance burden (with a few
known issues) and my current thinking is to drop it from Git for Windows
instead of leaving it in the current shape (I, for one, cannot justify
working on it myself, and the same seems to hold for everybody else, too).
See also https://github.com/git-for-windows/git/issues/5405.

Is there a chance that you could use the [Windows Subsystem for Linux
(WSL)](https://learn.microsoft.com/en-us/windows/wsl/) (i.e. the Linux
version of Git) for this migration, especially given that the
characterization as "migration" suggests that this is a one-off task?

Ciao,
Johannes

> What's different between what you expected and what actually happened?
> 
> - The process failed instead of succeeding, and the error was incredibly unhelpful, and seems like a bug in Git.pm.
> 
> 
> Anything else you want to add:
> 
> 
> Before this happened, another error happened first, which may or may not be related:
> 
> r1126 = 9d5f073cfcac00b9d8586923da4d045699244749 (refs/remotes/origin/trunk)
> Failed to strip path 'src/Lijsten/.gitignore' ((?^:^trunk(/|$)))
> 
> This also is not a very helpful error, as it gives no indication of *why* it failed to 'strip the path' (strip it of what, anyway?), nor why it failed on this particular commit.
> 
> Restarting the process by rerunning the same 'git svn clone' command seemed to 'fix' the problem by just continuing the process (which begs the question why the process aborted itself in the first place. Couldn't it just have continued?)
> 
> 
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.49.0.windows.1
> cpu: x86_64
> built from commit: cca1f38702730b35f52c29efd62864b85e85ddcc
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
> feature: fsmonitor--daemon
> libcurl: 8.12.1
> OpenSSL: OpenSSL 3.2.4 11 Feb 2025
> zlib: 1.3.1
> uname: Windows 10.0 22631
> compiler info: gnuc: 14.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): <unset>
> 
> 
> [Enabled Hooks]
> 
> C2 - Restricted use
> 

Cleaning up "contrib/" (was: git svn clone failed)

[Patrick Steinhardt]

On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:
> Hi Arnoud,
> 
> On Fri, 2 May 2025, BERENDSEN Arnoud wrote:
> 
> > What did you do before the bug happened? (Steps to reproduce your issue)
> > 
> > - I was migrating an SVN repository to Git using:
> > git svn clone <my-svn-repo> --stdlayout --authors-file=C:\path\to\my-authors-file.txt  --preserve-empty-dirs .
> > 
> > 
> > What did you expect to happen? (Expected behavior)
> > 
> > - I expect the entire process to succeed without errors.
> > When unavoidable errors do happen, I expect the error message to be helpful, give a clear description of what the underlying problem is, and how to solve it.
> > 
> > 
> > What happened instead? (Actual behavior)
> > 
> > - The migration failed with the folowwing error:
> > 
> > r2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)
> > Found possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814
> > W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
> > expected path: branches/trunk
> >     real path: trunk
> > Continuing ahead with trunk
> > W: Refspec glob conflict (ref: refs/remotes/origin/trunk):
> > expected path: branches/trunk
> >     real path: trunk
> > Continuing ahead with trunk
> > Initializing parent: refs/remotes/origin/<my-branch-name>@2814
> > Use of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.
> > Use of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.
> > fatal: Not a valid object name
> > ls-tree -z --name-only  data/OVK/: command returned error: 128
> 
> In Git for Windows, `git svn` is quite a maintenance burden (with a few
> known issues) and my current thinking is to drop it from Git for Windows
> instead of leaving it in the current shape (I, for one, cannot justify
> working on it myself, and the same seems to hold for everybody else, too).
> See also https://github.com/git-for-windows/git/issues/5405.
> 
> Is there a chance that you could use the [Windows Subsystem for Linux
> (WSL)](https://learn.microsoft.com/en-us/windows/wsl/) (i.e. the Linux
> version of Git) for this migration, especially given that the
> characterization as "migration" suggests that this is a one-off task?

I sometimes wonder whether we should move such basically-unmaintained
scripts out of the Git repository. They do a disservice to both us and
to our users as they create the wrong impression of being the sanctioned
way of doing a particular task even though they have only been gathering
dust for ages.

Many of the tools in "contrib/" fall into this category, and to the best
of my knowledge there isn't really a clear strategy for that directory.
So from my perspective, we should either rethink whether it is worth it
to have "contrib/" as part of Git, or we should at least do a spring
cleanup and drop bits that haven't seen any love in the last couple of
years.

Patrick

Re: Cleaning up "contrib/" (was: git svn clone failed)

[Johannes Schindelin]

Hi Patrick,

On Mon, 5 May 2025, Patrick Steinhardt wrote:

> On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:
> > 
> > On Fri, 2 May 2025, BERENDSEN Arnoud wrote:
> > 
> > > [... talks about `git svn` not working in Git for Windows ...]
> > 
> > In Git for Windows, `git svn` is quite a maintenance burden [... then
> > suggests to use Windows System for Linux (WSL) as a workaround ...].
> 
> I sometimes wonder whether we should move such basically-unmaintained
> scripts out of the Git repository. They do a disservice to both us and
> to our users as they create the wrong impression of being the sanctioned
> way of doing a particular task even though they have only been gathering
> dust for ages.
> 
> Many of the tools in "contrib/" fall into this category, and to the best
> of my knowledge there isn't really a clear strategy for that directory.
> So from my perspective, we should either rethink whether it is worth it
> to have "contrib/" as part of Git, or we should at least do a spring
> cleanup and drop bits that haven't seen any love in the last couple of
> years.

While I am thoroughly sympathetic to the idea of cleaning up `contrib/`
(which is a mixture of things that are quite well supported, such as the
Bash tab completion script, and of things that are the opposite of
maintained, such as `contrib/workdir/` that should have been dropped a
long time ago since it encourages relying on Git's internals and has been
superseded by `git worktree`), I cannot fail to notice that `git-svn`
isn't even in `contrib/`.

Instead, `git-svn` is in the same category as `git-archimport`,
`git-cvsserver`, `git-cvsexportcommit` and `git-cvsimport`, i.e. Git
commands that tried to facilitate transitioning from specific version
control systems that had been a lot more common than Git at the time, but
no longer are. Maybe `git-svn` is not quite as obsolete as the other
commands in that category, but they are all merely dust collectors in
Git's codebase.

Ciao,
Johannes

Re: Cleaning up "contrib/" (was: git svn clone failed)

[Patrick Steinhardt]

On Mon, May 05, 2025 at 09:36:06AM +0200, Johannes Schindelin wrote:
> Hi Patrick,
> 
> On Mon, 5 May 2025, Patrick Steinhardt wrote:
> 
> > On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:
> > > 
> > > On Fri, 2 May 2025, BERENDSEN Arnoud wrote:
> > > 
> > > > [... talks about `git svn` not working in Git for Windows ...]
> > > 
> > > In Git for Windows, `git svn` is quite a maintenance burden [... then
> > > suggests to use Windows System for Linux (WSL) as a workaround ...].
> > 
> > I sometimes wonder whether we should move such basically-unmaintained
> > scripts out of the Git repository. They do a disservice to both us and
> > to our users as they create the wrong impression of being the sanctioned
> > way of doing a particular task even though they have only been gathering
> > dust for ages.
> > 
> > Many of the tools in "contrib/" fall into this category, and to the best
> > of my knowledge there isn't really a clear strategy for that directory.
> > So from my perspective, we should either rethink whether it is worth it
> > to have "contrib/" as part of Git, or we should at least do a spring
> > cleanup and drop bits that haven't seen any love in the last couple of
> > years.
> 
> While I am thoroughly sympathetic to the idea of cleaning up `contrib/`
> (which is a mixture of things that are quite well supported, such as the
> Bash tab completion script, and of things that are the opposite of
> maintained, such as `contrib/workdir/` that should have been dropped a
> long time ago since it encourages relying on Git's internals and has been
> superseded by `git worktree`), I cannot fail to notice that `git-svn`
> isn't even in `contrib/`.

Oh, right you are!

> Instead, `git-svn` is in the same category as `git-archimport`,
> `git-cvsserver`, `git-cvsexportcommit` and `git-cvsimport`, i.e. Git
> commands that tried to facilitate transitioning from specific version
> control systems that had been a lot more common than Git at the time, but
> no longer are. Maybe `git-svn` is not quite as obsolete as the other
> commands in that category, but they are all merely dust collectors in
> Git's codebase.

Fully agreed.

Patrick

Re: Cleaning up "contrib/"

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Many of the tools in "contrib/" fall into this category, and to the best
> of my knowledge there isn't really a clear strategy for that directory.
> So from my perspective, we should either rethink whether it is worth it
> to have "contrib/" as part of Git, or we should at least do a spring
> cleanup and drop bits that haven't seen any love in the last couple of
> years.

Things in contrib/ should either move up (to become a part of the
core), move out (to become an independent project), or disappear.

But isn't git-svn not even part of contrib/?

Re: Cleaning up "contrib/"

[Patrick Steinhardt]

On Mon, May 05, 2025 at 12:10:15PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Many of the tools in "contrib/" fall into this category, and to the best
> > of my knowledge there isn't really a clear strategy for that directory.
> > So from my perspective, we should either rethink whether it is worth it
> > to have "contrib/" as part of Git, or we should at least do a spring
> > cleanup and drop bits that haven't seen any love in the last couple of
> > years.
> 
> Things in contrib/ should either move up (to become a part of the
> core), move out (to become an independent project), or disappear.

So this very much sounds like staging drivers in the Linux kernel, where
[1] seems to match the description of yours. The only problem is that I
haven't really seen the described movement -- many of the pieces haven't
been touched for years.

I'll probably just send a patch series to get rid of at least a subset
of them. I also think that we should adapt the README and rephrase it
according to what the modern intention of this directory is, which seems
to have changed.

Other than that we also have some bits and pieces that _are_ actively
maintained, but that just don't have a better place to live:

  - CMake.
  - Coccinelle rules.
  - Contacts.
  - Credential helpers.
  - Diff-highlight.
  - git-jump.
  - Shell completion.

Maybe they should be promoted and receive a proper home.

> But isn't git-svn not even part of contrib/?

Yeah, Dscho already corrected me.

Patrick

[1]: https://lwn.net/Articles/324279/

Re: Cleaning up "contrib/"

[Jeff King]

On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:

> Other than that we also have some bits and pieces that _are_ actively
> maintained, but that just don't have a better place to live:
> 
> [...]
>   - Diff-highlight.
>   - git-jump.

These two are due to me. I don't have a problem moving them into their
own projects if we want to clean out contrib.

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

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

-Peff

Re: Cleaning up "contrib/"

[brian m. carlson]

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

On 2025-05-12 at 13:50:17, Jeff King wrote:
> On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:
> 
> > Other than that we also have some bits and pieces that _are_ actively
> > maintained, but that just don't have a better place to live:
> > 
> > [...]
> >   - Diff-highlight.
> >   - git-jump.
> 
> These two are due to me. I don't have a problem moving them into their
> own projects if we want to clean out contrib.
> 
> 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.

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

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 definitely want us to keep these somewhere since they are quite
commonly used (even wincred) and getting rid of them will break a lot of
people and leave them without a secure credential storage option.  We
could promote them to the main repository and simply build them with a
Makefile knob (or by default on the appropriate platform) and in CI, in
which case we'd at least know they build.

I'm not volunteering to be _the_ maintainer for libsecret, but I will
definitely contribute to making it work since I use it.  This is much
like I am not _the_ maintainer for making Git work with Kerberos, but I
do certainly often fix it should it break.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: Cleaning up "contrib/"

[Patrick Steinhardt]

On Tue, May 13, 2025 at 12:13:30AM +0000, brian m. carlson wrote:
> On 2025-05-12 at 13:50:17, Jeff King wrote:
> > On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:
> > 
> > > Other than that we also have some bits and pieces that _are_ actively
> > > maintained, but that just don't have a better place to live:
> > > 
> > > [...]
> > >   - Diff-highlight.
> > >   - git-jump.
> > 
> > These two are due to me. I don't have a problem moving them into their
> > own projects if we want to clean out contrib.
> > 
> > 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.

Yup, diff-highlight is something I see recommended quite often.

> > >   - 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.
> 
> 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 definitely want us to keep these somewhere since they are quite
> commonly used (even wincred) and getting rid of them will break a lot of
> people and leave them without a secure credential storage option.  We
> could promote them to the main repository and simply build them with a
> Makefile knob (or by default on the appropriate platform) and in CI, in
> which case we'd at least know they build.
> 
> I'm not volunteering to be _the_ maintainer for libsecret, but I will
> definitely contribute to making it work since I use it.  This is much
> like I am not _the_ maintainer for making Git work with Kerberos, but I
> do certainly often fix it should it break.

Yup. I think safe credential helpers should rather be moved into our
official tree. This includes at least libsecret and osxkeychain. I'm not
sure about the netrc one though -- it's unsafe by nature, and I'm not
sure I would feel comfortable with shipping such a credential helper
that is known-unsafe.

Patrick

Re: Cleaning up "contrib/"

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Yup. I think safe credential helpers should rather be moved into our
> official tree. This includes at least libsecret and osxkeychain.

Yes.  s|^contrib/|| should be sufficient for them.

> I'm not
> sure about the netrc one though -- it's unsafe by nature, and I'm not
> sure I would feel comfortable with shipping such a credential helper
> that is known-unsafe.

That depends.  It is a known-convenient helper that can often be
used in an unsafe way, but when used with GPG encrypted netrc files,
especially on a single user box that is reasonably secured, it is
unfair to call it known-unsafe, I would have to say.

Thanks.

Re: Cleaning up "contrib/"

[Jeff King]

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

Re: Cleaning up "contrib/"

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Well, but it certainly is not more than what I currently need to do;
it does not make any difference whether it is housed in the contrib/
directory or in the tools/ directory.

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

Thanks for a redirect.