{"thread":{"id":"63384","subject":"git svn clone failed","startedAt":"2025-05-02T13:59:27Z","lastAt":"2025-05-14T20:05:39Z","messageCount":13,"participants":["BERENDSEN Arnoud","Johannes Schindelin","Patrick Steinhardt","Junio C Hamano","Jeff King","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"517113","messageId":"DU0PR07MB8465C407519BD5A8C8F933CE9D8D2@DU0PR07MB8465.eurprd07.prod.outlook.com","threadId":"63384","inReplyTo":null,"subject":"git svn clone failed","fromName":"BERENDSEN Arnoud","fromEmail":"arnoud.berendsen@soprasteria.com","sentAt":"2025-05-02T13:59:23Z","receivedAt":"2025-05-02T13:59:27Z","isPatch":false,"sender":{"key":"arnoud.berendsen@soprasteria.com","avatar":null},"body":"\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n- I was migrating an SVN repository to Git using:\ngit svn clone <my-svn-repo> --stdlayout --authors-file=C:\\path\\to\\my-authors-file.txt  --preserve-empty-dirs .\n\n\nWhat did you expect to happen? (Expected behavior)\n\n- I expect the entire process to succeed without errors.\nWhen 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.\n\n\nWhat happened instead? (Actual behavior)\n\n- The migration failed with the folowwing error:\n\nr2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)\nFound possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814\nW: Refspec glob conflict (ref: refs/remotes/origin/trunk):\nexpected path: branches/trunk\n    real path: trunk\nContinuing ahead with trunk\nW: Refspec glob conflict (ref: refs/remotes/origin/trunk):\nexpected path: branches/trunk\n    real path: trunk\nContinuing ahead with trunk\nInitializing parent: refs/remotes/origin/<my-branch-name>@2814\nUse of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.\nUse of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.\nfatal: Not a valid object name\nls-tree -z --name-only  data/OVK/: command returned error: 128\n\n\n\n\nWhat's different between what you expected and what actually happened?\n\n- The process failed instead of succeeding, and the error was incredibly unhelpful, and seems like a bug in Git.pm.\n\n\nAnything else you want to add:\n\n\nBefore this happened, another error happened first, which may or may not be related:\n\nr1126 = 9d5f073cfcac00b9d8586923da4d045699244749 (refs/remotes/origin/trunk)\nFailed to strip path 'src/Lijsten/.gitignore' ((?^:^trunk(/|$)))\n\nThis 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.\n\nRestarting 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?)\n\n\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.49.0.windows.1\ncpu: x86_64\nbuilt from commit: cca1f38702730b35f52c29efd62864b85e85ddcc\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: D:/git-sdk-64-build-installers/usr/bin/sh\nfeature: fsmonitor--daemon\nlibcurl: 8.12.1\nOpenSSL: OpenSSL 3.2.4 11 Feb 2025\nzlib: 1.3.1\nuname: Windows 10.0 22631\ncompiler info: gnuc: 14.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): <unset>\n\n\n[Enabled Hooks]\n\nC2 - Restricted use\n"},{"id":"517186","messageId":"3f3a0ee6-49a5-8013-7fe0-65c9ba8bfc3a@gmx.de","threadId":"63384","inReplyTo":"DU0PR07MB8465C407519BD5A8C8F933CE9D8D2@DU0PR07MB8465.eurprd07.prod.outlook.com","subject":"Re: git svn clone failed","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-05-04T08:19:06Z","receivedAt":"2025-05-04T08:19:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Arnoud,\n\nOn Fri, 2 May 2025, BERENDSEN Arnoud wrote:\n\n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> - I was migrating an SVN repository to Git using:\n> git svn clone <my-svn-repo> --stdlayout --authors-file=C:\\path\\to\\my-authors-file.txt  --preserve-empty-dirs .\n> \n> \n> What did you expect to happen? (Expected behavior)\n> \n> - I expect the entire process to succeed without errors.\n> 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.\n> \n> \n> What happened instead? (Actual behavior)\n> \n> - The migration failed with the folowwing error:\n> \n> r2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)\n> Found possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814\n> W: Refspec glob conflict (ref: refs/remotes/origin/trunk):\n> expected path: branches/trunk\n>     real path: trunk\n> Continuing ahead with trunk\n> W: Refspec glob conflict (ref: refs/remotes/origin/trunk):\n> expected path: branches/trunk\n>     real path: trunk\n> Continuing ahead with trunk\n> Initializing parent: refs/remotes/origin/<my-branch-name>@2814\n> Use of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.\n> Use of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.\n> fatal: Not a valid object name\n> ls-tree -z --name-only  data/OVK/: command returned error: 128\n\nIn Git for Windows, `git svn` is quite a maintenance burden (with a few\nknown issues) and my current thinking is to drop it from Git for Windows\ninstead of leaving it in the current shape (I, for one, cannot justify\nworking on it myself, and the same seems to hold for everybody else, too).\nSee also https://github.com/git-for-windows/git/issues/5405.\n\nIs there a chance that you could use the [Windows Subsystem for Linux\n(WSL)](https://learn.microsoft.com/en-us/windows/wsl/) (i.e. the Linux\nversion of Git) for this migration, especially given that the\ncharacterization as \"migration\" suggests that this is a one-off task?\n\nCiao,\nJohannes\n\n> What's different between what you expected and what actually happened?\n> \n> - The process failed instead of succeeding, and the error was incredibly unhelpful, and seems like a bug in Git.pm.\n> \n> \n> Anything else you want to add:\n> \n> \n> Before this happened, another error happened first, which may or may not be related:\n> \n> r1126 = 9d5f073cfcac00b9d8586923da4d045699244749 (refs/remotes/origin/trunk)\n> Failed to strip path 'src/Lijsten/.gitignore' ((?^:^trunk(/|$)))\n> \n> 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.\n> \n> 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?)\n> \n> \n> \n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n> \n> \n> [System Info]\n> git version:\n> git version 2.49.0.windows.1\n> cpu: x86_64\n> built from commit: cca1f38702730b35f52c29efd62864b85e85ddcc\n> sizeof-long: 4\n> sizeof-size_t: 8\n> shell-path: D:/git-sdk-64-build-installers/usr/bin/sh\n> feature: fsmonitor--daemon\n> libcurl: 8.12.1\n> OpenSSL: OpenSSL 3.2.4 11 Feb 2025\n> zlib: 1.3.1\n> uname: Windows 10.0 22631\n> compiler info: gnuc: 14.2\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): <unset>\n> \n> \n> [Enabled Hooks]\n> \n> C2 - Restricted use\n> \n"},{"id":"517204","messageId":"aBhZHA7av8bWH9Ac@pks.im","threadId":"63384","inReplyTo":"3f3a0ee6-49a5-8013-7fe0-65c9ba8bfc3a@gmx.de","subject":"Cleaning up \"contrib/\" (was: git svn clone failed)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-05-05T06:24:34Z","receivedAt":"2025-05-05T06:24:44Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:\n> Hi Arnoud,\n> \n> On Fri, 2 May 2025, BERENDSEN Arnoud wrote:\n> \n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > \n> > - I was migrating an SVN repository to Git using:\n> > git svn clone <my-svn-repo> --stdlayout --authors-file=C:\\path\\to\\my-authors-file.txt  --preserve-empty-dirs .\n> > \n> > \n> > What did you expect to happen? (Expected behavior)\n> > \n> > - I expect the entire process to succeed without errors.\n> > 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.\n> > \n> > \n> > What happened instead? (Actual behavior)\n> > \n> > - The migration failed with the folowwing error:\n> > \n> > r2814 = 1ecf20e2d14b45ee517b56f5f51b406801e9869b (refs/remotes/origin/trunk)\n> > Found possible branch point: https://<my-svn-repo> => https://<my-svn-repo>/branches/<my-branch-name>, 2814\n> > W: Refspec glob conflict (ref: refs/remotes/origin/trunk):\n> > expected path: branches/trunk\n> >     real path: trunk\n> > Continuing ahead with trunk\n> > W: Refspec glob conflict (ref: refs/remotes/origin/trunk):\n> > expected path: branches/trunk\n> >     real path: trunk\n> > Continuing ahead with trunk\n> > Initializing parent: refs/remotes/origin/<my-branch-name>@2814\n> > Use of uninitialized value $args[2] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1655.\n> > Use of uninitialized value $_[3] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1681.\n> > fatal: Not a valid object name\n> > ls-tree -z --name-only  data/OVK/: command returned error: 128\n> \n> In Git for Windows, `git svn` is quite a maintenance burden (with a few\n> known issues) and my current thinking is to drop it from Git for Windows\n> instead of leaving it in the current shape (I, for one, cannot justify\n> working on it myself, and the same seems to hold for everybody else, too).\n> See also https://github.com/git-for-windows/git/issues/5405.\n> \n> Is there a chance that you could use the [Windows Subsystem for Linux\n> (WSL)](https://learn.microsoft.com/en-us/windows/wsl/) (i.e. the Linux\n> version of Git) for this migration, especially given that the\n> characterization as \"migration\" suggests that this is a one-off task?\n\nI sometimes wonder whether we should move such basically-unmaintained\nscripts out of the Git repository. They do a disservice to both us and\nto our users as they create the wrong impression of being the sanctioned\nway of doing a particular task even though they have only been gathering\ndust for ages.\n\nMany of the tools in \"contrib/\" fall into this category, and to the best\nof my knowledge there isn't really a clear strategy for that directory.\nSo from my perspective, we should either rethink whether it is worth it\nto have \"contrib/\" as part of Git, or we should at least do a spring\ncleanup and drop bits that haven't seen any love in the last couple of\nyears.\n\nPatrick\n"},{"id":"517215","messageId":"5ffefc29-75ee-e278-448c-9124740d02fb@gmx.de","threadId":"63384","inReplyTo":"aBhZHA7av8bWH9Ac@pks.im","subject":"Re: Cleaning up \"contrib/\" (was: git svn clone failed)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-05-05T07:36:06Z","receivedAt":"2025-05-05T07:36:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Patrick,\n\nOn Mon, 5 May 2025, Patrick Steinhardt wrote:\n\n> On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:\n> > \n> > On Fri, 2 May 2025, BERENDSEN Arnoud wrote:\n> > \n> > > [... talks about `git svn` not working in Git for Windows ...]\n> > \n> > In Git for Windows, `git svn` is quite a maintenance burden [... then\n> > suggests to use Windows System for Linux (WSL) as a workaround ...].\n> \n> I sometimes wonder whether we should move such basically-unmaintained\n> scripts out of the Git repository. They do a disservice to both us and\n> to our users as they create the wrong impression of being the sanctioned\n> way of doing a particular task even though they have only been gathering\n> dust for ages.\n> \n> Many of the tools in \"contrib/\" fall into this category, and to the best\n> of my knowledge there isn't really a clear strategy for that directory.\n> So from my perspective, we should either rethink whether it is worth it\n> to have \"contrib/\" as part of Git, or we should at least do a spring\n> cleanup and drop bits that haven't seen any love in the last couple of\n> years.\n\nWhile I am thoroughly sympathetic to the idea of cleaning up `contrib/`\n(which is a mixture of things that are quite well supported, such as the\nBash tab completion script, and of things that are the opposite of\nmaintained, such as `contrib/workdir/` that should have been dropped a\nlong time ago since it encourages relying on Git's internals and has been\nsuperseded by `git worktree`), I cannot fail to notice that `git-svn`\nisn't even in `contrib/`.\n\nInstead, `git-svn` is in the same category as `git-archimport`,\n`git-cvsserver`, `git-cvsexportcommit` and `git-cvsimport`, i.e. Git\ncommands that tried to facilitate transitioning from specific version\ncontrol systems that had been a lot more common than Git at the time, but\nno longer are. Maybe `git-svn` is not quite as obsolete as the other\ncommands in that category, but they are all merely dust collectors in\nGit's codebase.\n\nCiao,\nJohannes\n"},{"id":"517237","messageId":"aBiIlDh0XAokwHZm@pks.im","threadId":"63384","inReplyTo":"5ffefc29-75ee-e278-448c-9124740d02fb@gmx.de","subject":"Re: Cleaning up \"contrib/\" (was: git svn clone failed)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-05-05T09:44:52Z","receivedAt":"2025-05-05T09:44:56Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, May 05, 2025 at 09:36:06AM +0200, Johannes Schindelin wrote:\n> Hi Patrick,\n> \n> On Mon, 5 May 2025, Patrick Steinhardt wrote:\n> \n> > On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote:\n> > > \n> > > On Fri, 2 May 2025, BERENDSEN Arnoud wrote:\n> > > \n> > > > [... talks about `git svn` not working in Git for Windows ...]\n> > > \n> > > In Git for Windows, `git svn` is quite a maintenance burden [... then\n> > > suggests to use Windows System for Linux (WSL) as a workaround ...].\n> > \n> > I sometimes wonder whether we should move such basically-unmaintained\n> > scripts out of the Git repository. They do a disservice to both us and\n> > to our users as they create the wrong impression of being the sanctioned\n> > way of doing a particular task even though they have only been gathering\n> > dust for ages.\n> > \n> > Many of the tools in \"contrib/\" fall into this category, and to the best\n> > of my knowledge there isn't really a clear strategy for that directory.\n> > So from my perspective, we should either rethink whether it is worth it\n> > to have \"contrib/\" as part of Git, or we should at least do a spring\n> > cleanup and drop bits that haven't seen any love in the last couple of\n> > years.\n> \n> While I am thoroughly sympathetic to the idea of cleaning up `contrib/`\n> (which is a mixture of things that are quite well supported, such as the\n> Bash tab completion script, and of things that are the opposite of\n> maintained, such as `contrib/workdir/` that should have been dropped a\n> long time ago since it encourages relying on Git's internals and has been\n> superseded by `git worktree`), I cannot fail to notice that `git-svn`\n> isn't even in `contrib/`.\n\nOh, right you are!\n\n> Instead, `git-svn` is in the same category as `git-archimport`,\n> `git-cvsserver`, `git-cvsexportcommit` and `git-cvsimport`, i.e. Git\n> commands that tried to facilitate transitioning from specific version\n> control systems that had been a lot more common than Git at the time, but\n> no longer are. Maybe `git-svn` is not quite as obsolete as the other\n> commands in that category, but they are all merely dust collectors in\n> Git's codebase.\n\nFully agreed.\n\nPatrick\n"},{"id":"517271","messageId":"xmqq5xieq3fs.fsf@gitster.g","threadId":"63384","inReplyTo":"aBhZHA7av8bWH9Ac@pks.im","subject":"Re: Cleaning up \"contrib/\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-05T19:10:15Z","receivedAt":"2025-05-05T19:10:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Many of the tools in \"contrib/\" fall into this category, and to the best\n> of my knowledge there isn't really a clear strategy for that directory.\n> So from my perspective, we should either rethink whether it is worth it\n> to have \"contrib/\" as part of Git, or we should at least do a spring\n> cleanup and drop bits that haven't seen any love in the last couple of\n> years.\n\nThings in contrib/ should either move up (to become a part of the\ncore), move out (to become an independent project), or disappear.\n\nBut isn't git-svn not even part of contrib/?\n\n"},{"id":"517291","messageId":"aBmg1_wlF2fuk96M@pks.im","threadId":"63384","inReplyTo":"xmqq5xieq3fs.fsf@gitster.g","subject":"Re: Cleaning up \"contrib/\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-05-06T05:40:39Z","receivedAt":"2025-05-06T05:40:47Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, May 05, 2025 at 12:10:15PM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > Many of the tools in \"contrib/\" fall into this category, and to the best\n> > of my knowledge there isn't really a clear strategy for that directory.\n> > So from my perspective, we should either rethink whether it is worth it\n> > to have \"contrib/\" as part of Git, or we should at least do a spring\n> > cleanup and drop bits that haven't seen any love in the last couple of\n> > years.\n> \n> Things in contrib/ should either move up (to become a part of the\n> core), move out (to become an independent project), or disappear.\n\nSo this very much sounds like staging drivers in the Linux kernel, where\n[1] seems to match the description of yours. The only problem is that I\nhaven't really seen the described movement -- many of the pieces haven't\nbeen touched for years.\n\nI'll probably just send a patch series to get rid of at least a subset\nof them. I also think that we should adapt the README and rephrase it\naccording to what the modern intention of this directory is, which seems\nto have changed.\n\nOther than that we also have some bits and pieces that _are_ actively\nmaintained, but that just don't have a better place to live:\n\n  - CMake.\n  - Coccinelle rules.\n  - Contacts.\n  - Credential helpers.\n  - Diff-highlight.\n  - git-jump.\n  - Shell completion.\n\nMaybe they should be promoted and receive a proper home.\n\n> But isn't git-svn not even part of contrib/?\n\nYeah, Dscho already corrected me.\n\nPatrick\n\n[1]: https://lwn.net/Articles/324279/\n"},{"id":"517846","messageId":"20250512135017.GC1191957@coredump.intra.peff.net","threadId":"63384","inReplyTo":"aBmg1_wlF2fuk96M@pks.im","subject":"Re: Cleaning up \"contrib/\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-05-12T13:50:17Z","receivedAt":"2025-05-12T13:50:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:\n\n> Other than that we also have some bits and pieces that _are_ actively\n> maintained, but that just don't have a better place to live:\n> \n> [...]\n>   - Diff-highlight.\n>   - git-jump.\n\nThese two are due to me. I don't have a problem moving them into their\nown projects if we want to clean out contrib.\n\nI think diff-highlight is something that _should_ eventually happen\ninside git-diff itself (because it would be more efficient and we could\ndo a better job). But it wouldn't share any implementation with what's\nin contrib/.\n\n>   - Credential helpers.\n\nThese ones are tricky. In theory they could be spun off into their own\nprojects, and we already have examples in the wild of things like GCM\nwhich are maintained totally separately.\n\nBut I think we may need to find people to step up as maintainers. In\nparticular, I think osxkeychain is probably used by a lot of people, and\nprobably shouldn't just go away. But I don't know how the maintainer\nwould be. I wrote it originally, but don't (and never did) use it\nmyself, or even have access to a macOS machine.\n\n-Peff\n"},{"id":"517919","messageId":"aCKOqs52TDZDvAXJ@tapette.crustytoothpaste.net","threadId":"63384","inReplyTo":"20250512135017.GC1191957@coredump.intra.peff.net","subject":"Re: Cleaning up \"contrib/\"","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-05-13T00:13:30Z","receivedAt":"2025-05-13T00:13:38Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-05-12 at 13:50:17, Jeff King wrote:\n> On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:\n> \n> > Other than that we also have some bits and pieces that _are_ actively\n> > maintained, but that just don't have a better place to live:\n> > \n> > [...]\n> >   - Diff-highlight.\n> >   - git-jump.\n> \n> These two are due to me. I don't have a problem moving them into their\n> own projects if we want to clean out contrib.\n> \n> I think diff-highlight is something that _should_ eventually happen\n> inside git-diff itself (because it would be more efficient and we could\n> do a better job). But it wouldn't share any implementation with what's\n> in contrib/.\n\nI think there are definitely users of diff-highlight.  I remember seeing\na reference to it recently and not realizing it was in contrib, but it\nis actually used by others.  I don't use it myself, though.\n\n> >   - Credential helpers.\n> \n> These ones are tricky. In theory they could be spun off into their own\n> projects, and we already have examples in the wild of things like GCM\n> which are maintained totally separately.\n> \n> But I think we may need to find people to step up as maintainers. In\n> particular, I think osxkeychain is probably used by a lot of people, and\n> probably shouldn't just go away. But I don't know how the maintainer\n> would be. I wrote it originally, but don't (and never did) use it\n> myself, or even have access to a macOS machine.\n\nThese are often shipped by distributors.  Apple ships osxkeychain, as\ndoes Homebrew.  Many Linux distros ship libsecret and it's the\nrecommended choice for desktop Linux.\n\nwincred, while not super popular, is still used and is smaller and\nlighter than GCM.  It doesn't actually look like GCM is seeing a great\ndeal of maintenance either at this point, so I'd say they're about\nequally well maintained.  Since I don't use Windows, I don't know if\nthere are other usecases (such as noninteractive uses) that are better\nsupported by wincred, but I'd recommend keeping it.\n\nI definitely want us to keep these somewhere since they are quite\ncommonly used (even wincred) and getting rid of them will break a lot of\npeople and leave them without a secure credential storage option.  We\ncould promote them to the main repository and simply build them with a\nMakefile knob (or by default on the appropriate platform) and in CI, in\nwhich case we'd at least know they build.\n\nI'm not volunteering to be _the_ maintainer for libsecret, but I will\ndefinitely contribute to making it work since I use it.  This is much\nlike I am not _the_ maintainer for making Git work with Kerberos, but I\ndo certainly often fix it should it break.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"517932","messageId":"aCMLgaWXr_gM8g3l@pks.im","threadId":"63384","inReplyTo":"aCKOqs52TDZDvAXJ@tapette.crustytoothpaste.net","subject":"Re: Cleaning up \"contrib/\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-05-13T09:06:09Z","receivedAt":"2025-05-13T09:06:14Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, May 13, 2025 at 12:13:30AM +0000, brian m. carlson wrote:\n> On 2025-05-12 at 13:50:17, Jeff King wrote:\n> > On Tue, May 06, 2025 at 07:40:39AM +0200, Patrick Steinhardt wrote:\n> > \n> > > Other than that we also have some bits and pieces that _are_ actively\n> > > maintained, but that just don't have a better place to live:\n> > > \n> > > [...]\n> > >   - Diff-highlight.\n> > >   - git-jump.\n> > \n> > These two are due to me. I don't have a problem moving them into their\n> > own projects if we want to clean out contrib.\n> > \n> > I think diff-highlight is something that _should_ eventually happen\n> > inside git-diff itself (because it would be more efficient and we could\n> > do a better job). But it wouldn't share any implementation with what's\n> > in contrib/.\n> \n> I think there are definitely users of diff-highlight.  I remember seeing\n> a reference to it recently and not realizing it was in contrib, but it\n> is actually used by others.  I don't use it myself, though.\n\nYup, diff-highlight is something I see recommended quite often.\n\n> > >   - Credential helpers.\n> > \n> > These ones are tricky. In theory they could be spun off into their own\n> > projects, and we already have examples in the wild of things like GCM\n> > which are maintained totally separately.\n> > \n> > But I think we may need to find people to step up as maintainers. In\n> > particular, I think osxkeychain is probably used by a lot of people, and\n> > probably shouldn't just go away. But I don't know how the maintainer\n> > would be. I wrote it originally, but don't (and never did) use it\n> > myself, or even have access to a macOS machine.\n> \n> These are often shipped by distributors.  Apple ships osxkeychain, as\n> does Homebrew.  Many Linux distros ship libsecret and it's the\n> recommended choice for desktop Linux.\n> \n> wincred, while not super popular, is still used and is smaller and\n> lighter than GCM.  It doesn't actually look like GCM is seeing a great\n> deal of maintenance either at this point, so I'd say they're about\n> equally well maintained.  Since I don't use Windows, I don't know if\n> there are other usecases (such as noninteractive uses) that are better\n> supported by wincred, but I'd recommend keeping it.\n> \n> I definitely want us to keep these somewhere since they are quite\n> commonly used (even wincred) and getting rid of them will break a lot of\n> people and leave them without a secure credential storage option.  We\n> could promote them to the main repository and simply build them with a\n> Makefile knob (or by default on the appropriate platform) and in CI, in\n> which case we'd at least know they build.\n> \n> I'm not volunteering to be _the_ maintainer for libsecret, but I will\n> definitely contribute to making it work since I use it.  This is much\n> like I am not _the_ maintainer for making Git work with Kerberos, but I\n> do certainly often fix it should it break.\n\nYup. I think safe credential helpers should rather be moved into our\nofficial tree. This includes at least libsecret and osxkeychain. I'm not\nsure about the netrc one though -- it's unsafe by nature, and I'm not\nsure I would feel comfortable with shipping such a credential helper\nthat is known-unsafe.\n\nPatrick\n"},{"id":"517956","messageId":"xmqq8qn0h2fe.fsf@gitster.g","threadId":"63384","inReplyTo":"aCMLgaWXr_gM8g3l@pks.im","subject":"Re: Cleaning up \"contrib/\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-13T16:59:33Z","receivedAt":"2025-05-13T16:59:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Yup. I think safe credential helpers should rather be moved into our\n> official tree. This includes at least libsecret and osxkeychain.\n\nYes.  s|^contrib/|| should be sufficient for them.\n\n> I'm not\n> sure about the netrc one though -- it's unsafe by nature, and I'm not\n> sure I would feel comfortable with shipping such a credential helper\n> that is known-unsafe.\n\nThat depends.  It is a known-convenient helper that can often be\nused in an unsafe way, but when used with GPG encrypted netrc files,\nespecially on a single user box that is reasonably secured, it is\nunfair to call it known-unsafe, I would have to say.\n\nThanks.\n\n\n"},{"id":"518063","messageId":"20250514181938.GC2196784@coredump.intra.peff.net","threadId":"63384","inReplyTo":"aCKOqs52TDZDvAXJ@tapette.crustytoothpaste.net","subject":"Re: Cleaning up \"contrib/\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-05-14T18:19:38Z","receivedAt":"2025-05-14T18:19:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 13, 2025 at 12:13:30AM +0000, brian m. carlson wrote:\n\n> > I think diff-highlight is something that _should_ eventually happen\n> > inside git-diff itself (because it would be more efficient and we could\n> > do a better job). But it wouldn't share any implementation with what's\n> > in contrib/.\n> \n> I think there are definitely users of diff-highlight.  I remember seeing\n> a reference to it recently and not realizing it was in contrib, but it\n> is actually used by others.  I don't use it myself, though.\n\nOh, there definitely are users. Sometimes they contact me outside the\nlist. ;) I thought the discussion around contrib/ here was more around\n\"should things in contrib/ spin out to their own projects\", and not\n\"should they be removed and forgotten\". :)\n\nI am perfectly happy if these things stay in contrib/ forever. I was\nonly voicing that I'd be OK taking them on as outside projects if we\ndidn't want to keep them in-tree anymore.\n\n> > >   - Credential helpers.\n> > \n> > These ones are tricky. In theory they could be spun off into their own\n> > projects, and we already have examples in the wild of things like GCM\n> > which are maintained totally separately.\n> > \n> > But I think we may need to find people to step up as maintainers. In\n> > particular, I think osxkeychain is probably used by a lot of people, and\n> > probably shouldn't just go away. But I don't know how the maintainer\n> > would be. I wrote it originally, but don't (and never did) use it\n> > myself, or even have access to a macOS machine.\n> \n> These are often shipped by distributors.  Apple ships osxkeychain, as\n> does Homebrew.  Many Linux distros ship libsecret and it's the\n> recommended choice for desktop Linux.\n\nRight, I know people use them. What I meant was that if we wanted to\nspin them to out-of-tree projects, we'd need somebody to volunteer to be\nthe maintainer of those projects. If they stay in-tree we can be a bit\nlooser (your \"I don't want to be _the_ maintainer, but I can\ncontribute\").\n\nIt does put more load on Junio, though. E.g., if there is a security\nproblem the project has to deal with embargoed release engineering,\nwhereas a separate project would do its own releases.\n\n> wincred, while not super popular, is still used and is smaller and\n> lighter than GCM.  It doesn't actually look like GCM is seeing a great\n> deal of maintenance either at this point, so I'd say they're about\n> equally well maintained.  Since I don't use Windows, I don't know if\n> there are other usecases (such as noninteractive uses) that are better\n> supported by wincred, but I'd recommend keeping it.\n\nI don't use Windows, so I don't have a personal opinion. Code may not\nsee updates because it mostly works, or because hardly anybody is using\nit. Or people may be using it but it's still broken. ;)\n\nLast time wincred had a security hole (in 2020), the phrase \"unsafe and\nunmaintained\" was thrown about on the security list, but we ultimately\nfixed at least the immediate issue. But I find its general matching\nstrategy to be not very confidence-inspiring.\n\nDscho (or anybody else familiar with Windows) may want to comment\nfurther.\n\n-Peff\n"},{"id":"518068","messageId":"xmqqo6vv7yb3.fsf@gitster.g","threadId":"63384","inReplyTo":"20250514181938.GC2196784@coredump.intra.peff.net","subject":"Re: Cleaning up \"contrib/\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-14T20:05:36Z","receivedAt":"2025-05-14T20:05:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Right, I know people use them. What I meant was that if we wanted to\n> spin them to out-of-tree projects, we'd need somebody to volunteer to be\n> the maintainer of those projects. If they stay in-tree we can be a bit\n> looser (your \"I don't want to be _the_ maintainer, but I can\n> contribute\").\n>\n> It does put more load on Junio, though. E.g., if there is a security\n> problem the project has to deal with embargoed release engineering,\n> whereas a separate project would do its own releases.\n\nWell, but it certainly is not more than what I currently need to do;\nit does not make any difference whether it is housed in the contrib/\ndirectory or in the tools/ directory.\n\n> Last time wincred had a security hole (in 2020), the phrase \"unsafe and\n> unmaintained\" was thrown about on the security list, but we ultimately\n> fixed at least the immediate issue. But I find its general matching\n> strategy to be not very confidence-inspiring.\n>\n> Dscho (or anybody else familiar with Windows) may want to comment\n> further.\n\nThanks for a redirect.\n"}]}