git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'George Ogden'" <george.ogden.human@gmail.com>, <git@vger.kernel.org>
Subject: RE: [Feature Request] Support for sharing root-level files across repositories
Date: Mon, 29 Sep 2025 13:25:26 -0400	[thread overview]
Message-ID: <03d601dc3166$0f302170$2d906450$@nexbridge.com> (raw)
In-Reply-To: <CAJ5EAUw_VN4GXiHYJq0et8oZN0L+AHZz+ROLtK3Hxdp3SEL3=g@mail.gmail.com>

On September 26, 2025 4:33 AM, George Ogden wrote:
>Hello Git developers,
>
>Firstly, apologies if this has already been discussed or if there is a way to solve this
>problem that I am not aware of.
>
>Motivation
>
>Git submodules are very useful for sharing directories between repositories.
>However, in some workflows, there is a need to share a single file that must live in
>the repository root.
>
>A concrete example is .pre-commit-config.yaml. I maintain a standard template
>across many repositories. When I add a new hook or update a version, I have to
>manually update the file in each repository. I could use a submodule for this, but
>submodules always appear in a subdirectory — not at the root where tools expect
>this file.
>
>The same issue arises with other configuration files that need to reside at the top
>level of a project (linters, CI configs, licenses, etc.).
>
>Proposal
>
>It would be helpful if Git provided a way to share a file across repositories so that it
>appears at the root of the working tree, without requiring a separate build step,
>symlink, or copy operation.
>
>I understand there are alternative approaches (subtrees, packages, external
>tooling), but they all involve extra indirection. Having first-class support within Git
>for this use case would make it much simpler and more consistent.
>
>Thanks
>
>Thank you for your work maintaining and evolving Git! I would greatly appreciate
>any feedback on whether this idea has been considered before, and if there are
>technical reasons it may not fit Git’s model.

I have been thinking about a current use case for this RFE. Consider
GNU/Configure-based projects where we have config.guess and config.sub in the
repository root. These two files are independent of the project itself and truly
should be shared and managed from a single authoritative source. It can be a
real delay/pain to wait for the project to manually update these two files
from an upstream to get platform support for their project. 

In order to support something like this, we might need a submodule concept
That supports something like a link upwards. Or this might be something
That could be part of the sparse-checkout infrastructure. I'm not sure, but I
Do think there is merit to this. It could also apply to organisations that have
cross-application root certificates that need to be in the same directory
as the application root.

Just my musings.
--Randall


  reply	other threads:[~2025-09-29 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-26  8:33 [Feature Request] Support for sharing root-level files across repositories George Ogden
2025-09-29 17:25 ` rsbecker [this message]
2025-09-29 19:32   ` George Ogden
2025-09-29 21:17   ` Ben Knoble

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

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

  git send-email \
    --in-reply-to='03d601dc3166$0f302170$2d906450$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=george.ogden.human@gmail.com \
    --cc=git@vger.kernel.org \
    /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.
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 NNTP newsgroup(s).