From: sporteka2@disroot.org
To: git@vger.kernel.org
Subject: [Feature] linked files — one source, multiple paths, always identical
Date: Sun, 19 Jul 2026 05:46:09 +0300 [thread overview]
Message-ID: <6b78724639d248e0fa9089035b1ff2fb.sporteka2@disroot.org> (raw)
Hi all,
I would like to propose a 'linked files' mechanism for Git: a file can be
declared to mirror another file in the same repository, so the two are
always byte-identical. The tooling would enforce identity and keep the
copies in sync automatically — no manual copy, no symlink, no commit hook.
== Motivation ==
Many projects need the same source file available from multiple paths:
- a library core reused by an example folder
(examples/demo/core.js must equal the root core.js);
- a shared header copied into submodules;
- documentation snippets embedded in several places.
Today the only ways to keep them identical are:
- Copy — drifts whenever one side is edited;
- Symlink — breaks on some archive downloads and cross-filesystem;
- Hardlink — lost by every git checkout / git reset;
- Commit hook — a workaround, not a platform guarantee, and runs only
at commit time.
None of these guarantees that the files are identical at any moment,
which is what a maintainer actually wants.
== Proposed mechanism ==
Add a declarative file (e.g. .gitlinks, similar to .gitignore) mapping
a linked path to its source:
.gitlinks
# linked path source path
examples/demo/core.js core.js
The tooling would then:
- On commit — reject the commit if a linked file differs from its source
(or auto-overwrite it from the source);
- On checkout / clone — materialise the linked file from the source
(hardlink when the filesystem allows, otherwise an identical copy);
- On archive / ZIP download — keep the link so the downloaded tree
stays correct;
- On edit — editing either path updates both, so divergence is
impossible.
== Why this belongs at the tooling level ==
Git already stores content-addressed blobs, so two identical files share
one blob internally. The missing piece is a working-tree guarantee that
the paths stay identical.
== Concrete first step (smaller scope) ==
Even without full 'linked files', a valuable first deliverable would be:
git archive should preserve hardlinks between identical files, the way it
already preserves symlinks. That alone would let a maintainer hardlink a
file locally and have the archive keep the two entries pointing at one
object.
== Alternatives considered ==
- Submodules / subtrees — heavier, separate history or full copy, not
'same file'.
- Symlinks — already preserved by git archive, but break on some download
tools and cross-filesystem.
- Commit hooks — work only at commit time, easy to forget, not enforced.
I would appreciate feedback on this proposal.
Thanks,
sporteka
reply other threads:[~2026-07-19 2:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=6b78724639d248e0fa9089035b1ff2fb.sporteka2@disroot.org \
--to=sporteka2@disroot.org \
--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