git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Philip Oakley <philipoakley@iee.email>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Christian Couder <christian.couder@gmail.com>,
	Jeff King <peff@peff.net>, git <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: Git in Outreachy?
Date: Wed, 16 Sep 2020 20:43:17 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2009162040420.56@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <5be2fca8-2dbd-115e-b3bb-5783daeba4a3@iee.email>

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

  reply	other threads:[~2020-09-16 18:43 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28  6:56 Jeff King
2020-08-31  6:55 ` Christian Couder
2020-09-03  6:00   ` Jonathan Nieder
2020-09-04 14:14     ` Philip Oakley
2020-09-07 18:49       ` Johannes Schindelin
2020-09-16 15:16         ` Philip Oakley
2020-09-16 18:43           ` Johannes Schindelin [this message]
2020-09-17 14:42             ` Philip Oakley
2020-09-09 18:26     ` Taylor Blau
2020-09-10  1:39       ` Jonathan Nieder
2020-09-10  2:19         ` Taylor Blau
2020-09-16  9:12     ` Christian Couder
2020-09-16  6:42   ` Christian Couder
2020-08-31 17:41 ` Junio C Hamano
2020-08-31 18:05 ` Emily Shaffer
2020-09-01 12:51   ` Jeff King
2020-09-03  5:41     ` Jeff King
2020-09-15 17:35       ` Jeff King
2020-09-15 17:55         ` Kaartic Sivaraam
2020-09-15 18:02           ` Jeff King
2020-09-19  8:12         ` Christian Couder
2020-09-19 15:10           ` Phillip Wood
2020-09-16  8:45     ` Christian Couder
2020-09-02  4:00 ` Johannes Schindelin
2020-09-16  9:01   ` Christian Couder
2020-09-16  9:45     ` Phillip Wood
2020-09-17  9:43     ` Christian Couder
2020-09-17 10:14       ` Phillip Wood
2020-09-18  8:37         ` Christian Couder
2020-09-17 15:34       ` Elijah Newren
2020-09-18  8:42         ` Christian Couder
2020-09-27 16:59     ` Kaartic Sivaraam
2020-09-27 21:16       ` Christian Couder
2020-10-29 10:13         ` Christian Couder
2020-09-06 18:56 ` Kaartic Sivaraam
2020-09-07 18:55   ` Johannes Schindelin
2020-09-16  9:35     ` Christian Couder
2020-09-16 20:27       ` Johannes Schindelin
2020-09-19  7:40         ` Christian Couder
2020-09-20 15:06           ` Johannes Schindelin
2020-09-20 16:31   ` Kaartic Sivaraam
2020-09-21  4:22     ` Christian Couder
2020-09-21  7:59       ` Kaartic Sivaraam
2020-09-21 20:56       ` Shourya Shukla
2021-09-03  2:40 Taylor Blau
2021-09-03 18:33 ` Emily Shaffer
2021-09-04  4:30 ` Christian Couder
2021-09-04  7:40   ` ZheNing Hu
2021-09-04 12:50     ` Jeff King
2021-09-05  8:58       ` ZheNing Hu
2021-09-06 12:36         ` Matheus Tavares Bernardino
2021-09-07  5:50           ` ZheNing Hu
2021-09-04 17:51 ` Taylor Blau
2021-09-18 16:10 ` Taylor Blau
2021-09-20  7:45   ` ZheNing Hu
2021-09-20 14:52     ` Christian Couder
2021-09-20 15:15       ` Christian Couder
2021-09-21  5:41         ` ZheNing Hu
2021-09-21 15:39           ` Christian Couder
2021-09-22 15:01             ` ZheNing Hu
2021-09-21  5:39       ` ZheNing Hu
2021-09-21 15:35         ` Christian Couder
2021-09-22 14:58           ` ZheNing Hu
2021-09-21 21:25   ` Taylor Blau
2021-09-29 14:18     ` Christian Couder
2021-09-29 17:34       ` Taylor Blau
2021-09-29 20:30         ` Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2009162040420.56@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=philipoakley@iee.email \
    --subject='Re: Git in Outreachy?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).