Re: Git in Outreachy?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 7, 2020, 18:49 UTC
Message-ID: <nycvar.QRO.7.76.6.2009060933480.56@tvgsbejvaqbjf.bet>
In-Reply-To: <a3613b9d-730a-7a4b-c84b-c833490fcea6@iee.email>

Hi Philip,

On Fri, 4 Sep 2020, Philip Oakley wrote:

Show 30 quoted lines

> 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

Show 6 quoted lines

>
> Philip
>
> [1]
> https://github.com/git-for-windows/git/issues/2803#issuecomment-687161483
>