如何使用 Git LFS 跟踪存储库的任何子目录中的任何（任意）文件 - 但不跟踪其根目录中的任何文件？

Question

I have searched for multiple days to find a solution and did lots of trial and error games without being successful.

The idea is simply to create a library repository for tons of binary (and all related) files which intrinsically makes 100% sure that any added file in the future by any user gets tracked by lfs.

However files like.gitattributes, .gitignore, README.md, etc. in the root should of course be excluded.

To understand the wildcard rules of .gitignore one already needs a PhD, the .gitattributes documentation mentions two more exceptions (like forbidding negations) and I can't find anything helpful about whether Git LFS even follows these "nasty rules".

There might be already a few somewhat related questions/answers on so, but I couldn't find anything useful for my problem so far.

Any help is much appreciated. Thanks in advance!

Edit: I've already tested patterns like */* , */*.* , */** , **/* , **/** , /**/* , ... with lfs track "{pattern}" but sometimes (depending on the worktree status) these wildcard patterns get translated into huge unsorted lists of named file fractions in.gitattributes (without shell expansion). If the wildcards however remain in.gitattributes, then weird things happen like newly matched files not being tracked anymore after merges, or complains about files that should be pointers, files listed in git lfs status suddenly disappear... I should also mention that git lfs migrate import always renders the wildcards in.gitattributes into completely useless lists of existing files. And something like git lfs migrate --include="{pattern}" is silently ignored and seems to track just a few arbitrarily selected file extensions?. I even managed to get a repository in a state where I could push to a remote without any errors and afterwards all files were missing on the server - unbelievable. To me it seems that Git LFS is totally unreliable and unpredictable. But maybe I'm doing something totally wrong.

Btw, here is some version info from my tests and Git LFS is installed gloablly:

• git-lfs/2.3.4 (GitHub; linux amd64; go 1.8.3)
• git version 2.26.2

Answer 1

I had to do something very similar for a legacy system. Here's what I found worked: ignore everything, then selectively unignore. Each parent directory must be individually unignored before its children can be unignored.

Let's say you want to store only /bin, /sbin and /usr/local/bin.

# Ignore everything
*

# Unignore .gitignore so we can commit it.
!.gitignore

# Unignore /bin and its contents
!bin/
!bin/**
!sbin/
!sbin/**

# Unignore /usr/local/bin and its contents
!usr/
!usr/local/
!usr/local/bin/
!usr/local/bin/**

# Reignore log, lock and tmp files.
*.lock
*.log
.#*
*~
.*.swp

---

The idea is simply to create a library repository for tons of binary (and all related) files which intrinsically makes 100% sure that any added file in the future by any user gets tracked by lfs.

Neither Git nor Git LFS are appropriate solutions. They are not release managers. Git LFS adds unnecessary complication, it is not necessary for small binary files like executables.

I did it as a stopgap solution. I was handed a completely uncontrolled legacy system where production files were being edited live; it was better than nothing, but it sucked. A better solution should be found ASAP.

In my case, I incrementally replaced its funcionality with managed servers, packaged software, dependency management, individual code repositories, and a proper release pipeline. Then I decommissioned the legacy servers. I would suggest you also only use this as a stopgap and investigate a proper solution.

An alternative stopgap is to use backup software to make incremental backups. The "history" of a binary-only repository is not particularly useful.