Hi Philip, On Fri, 4 Sep 2020, Philip Oakley wrote: > On 03/09/2020 07:00, Jonathan Nieder wrote: > > > > Christian Couder wrote: > > > >> I would appreciate help to find project ideas though. Are there still > >> scripts that are worth converting to C (excluding git-bisect.sh and > >> git-submodule.sh that are still worked on)? Are there worthy > >> refactorings or improvements that we could propose as projects? > > I think setting up something like snowpatch[*] to run CI on patches > > that have hit the mailing list but not yet hit "seen" might be a good > > project for an interested applicant (and I'd be interested in > > co-mentoring if we find a taker). > > > > Some other topics that could be interesting: > > - better support for handling people's name changing > > - making signing features such as signed push easier to use (for > > example by allowing signing with SSH keys to simplify PKI) and more > > useful (for example by standardizing a way to publish signed push > > logs in Git) > > - protocol: sharing notes and branch descriptions > > - formats: on-disk reverse idx > > - obliterate > > - cache server to take advantage of multiple promisors+packfile URIs > > > > Jonathan > > > > [*] https://github.com/ruscur/snowpatch > A suggestion with high value for the Windows community > - mechanism to map file names between the index and the local FS, should > a repos file/path name already be taken, or invalid. [1] This suggestion keeps coming up, but I cannot help but highly doubt that it will prove useful in practice: if your source code contains a file called `aux.c`, chances are that your build system lists this file specifically, and it won't do at all to "magically" rename it to, say, `aux_.c` during checkout. In contrast, I think a much more useful project would be to relax the `core.protectNTFS` protections to cover only the files that will be written to disk, and not bother even checking the files excluded from a sparse-checkout for invalid file names on NTFS. This is trickier, of course, than meets the eye: we would still want to be _very_ careful to ensure that the unchecked file names will _never_ make it to the disk. And, slightly related, the question whether checking for `.git` (or `GIT~1`) would be likewise weakened, or whether that is too dangerous to allow even in `skip-worktree` entries. Not necessarily decisions you would want to burden a first-time contributor with. Ciao, Dscho > > Philip > > [1] > https://github.com/git-for-windows/git/issues/2803#issuecomment-687161483 >
