From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent
Date: Tue, 16 Aug 2016 15:10:46 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1608161502240.4924@virtualbox> (raw)
In-Reply-To: <20160815184315.cyhln2bxg465lq2l@sigill.intra.peff.net>
Hi Peff & Junio,
On Mon, 15 Aug 2016, Jeff King wrote:
> On Mon, Aug 15, 2016 at 09:57:52AM -0700, Junio C Hamano wrote:
>
> > I wonder if we already have a good mechanism to allow a project and
> > its participants (say, "me") to declare "in this project, pathnames
> > must conform to this rule" and help them avoid creating a tree that
> > violates the rule customized to their project.
> >
> > I guess "write_index_as_tree()" would be one of the central places to
> > hook into and that covers an individual contributor or a patch applier
> > who ends up adding offending paths to the project, as well as a merge
> > made in response to a pull request (unless it is a fast-forward)
> > [*1*]. The pre-receive hook can also be used to inspect and reject an
> > attempt to push an offending tree into the history.
FWIW I think it should be at a different level. See below for more
details.
> > Such a mechanism would allow a project that wants participation by
> > folks with case insensitive filesystems to ensure that they do not
> > create a directory that has both xt_TCPMSS.h and xt_tcpmss.h at the
> > same time, for example, but the mechanism needs to allow visibility
> > into more than just a single path when the custom check is made (e.g.
> > a hook run in "write_index_as_tree()" can see all entries in the index
> > to make the decision; if we were to also hook into "add_to_index()",
> > the hook must be able to see other entries in the index to which the
> > new entry is being added).
>
> I am not convinced this mechanism needs to be built into git. Because it
> happens to be about filenames, git at least has a hope of making sense
> of the various project rules.
Both of you gentle people may recall a conversation in December 2014 when
we scrambled to plug a hole where maliciously-chosen file names would have
allowed to wreak havoc with a local Git repository's config (among other
things).
We did plug it, but not before I proposed to exclude many more file names
than just maliciously-chosen ones. For example, I wanted to exclude all
file names that are illegal on Windows when core.protectNTFS was set to
true.
If we were to implement this "let's help cross-platform projects"
functionality, it would be at that same level.
However, I have to agree with Junio that Git is *not* targeting *all*
platforms. Conversely, any solution we implement to try to be helpful by
pointing out unportable file names will certainly fall short of *some*
project's requirement.
Given that we have no shortage of problems to solve, I would vote for
addressing portability only as far as Git and its intended target
platforms are concerned.
Ciao,
Dscho
next prev parent reply other threads:[~2016-08-16 13:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 14:08 [PATCH] t/Makefile: make sure that file names are truly platform-independent Johannes Schindelin
2016-08-15 16:06 ` Junio C Hamano
2016-08-15 16:57 ` Junio C Hamano
2016-08-15 18:43 ` Jeff King
2016-08-16 13:10 ` Johannes Schindelin [this message]
2016-08-16 14:55 ` Jeff King
2016-08-16 15:37 ` Johannes Schindelin
2016-08-16 15:39 ` Jeff King
2016-08-15 21:03 ` Junio C Hamano
2016-08-16 8:29 ` Johannes Schindelin
2016-08-16 8:42 ` Johannes Schindelin
2016-08-16 9:53 ` Junio C Hamano
2016-08-16 10:07 ` Junio C Hamano
2016-08-16 15:10 ` Johannes Schindelin
2016-08-16 21:10 ` Johannes Sixt
2016-08-16 8:50 ` [PATCH v2] t/Makefile: make sure that paths can be checked out on platforms we care Johannes Schindelin
2016-08-16 15:13 ` [PATCH v3] t/Makefile: ensure that paths are valid " Johannes Schindelin
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=alpine.DEB.2.20.1608161502240.4924@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).