Re: Git in Outreachy?

> Hi Philip,
>
> On Wed, 16 Sep 2020, Philip Oakley wrote:
>
>> On 07/09/2020 19:49, Johannes Schindelin wrote:
>>> 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.
>> I'd disagree with that line of reasoning in the sense that if someone is
>> on Windows wanting to 'view' a repo that was developed on Linux, with
>> colons in pathnames, and filenames like aux.c we shouldn't be
>> deliberately de-include them just because of those file/pathname
>> 'accidents.
> If someone wanted to just have a look, they usually make use of the web
> interface of a Git hosting service and look at the file there.
>
> Even if somebody insists on cloning the entire history, they can easily
> look at the file via `git show origin/HEAD:<path>`.
>
> The most likely users who really need those files to be checked out are
> the ones who need to build the project, and that's simply not possible
> with "magically" renamed files.
>
> Ciao,
> Dscho