Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LFS detects objects as “In Repo” that are not #20413

Open
HermannDppes opened this issue Jul 19, 2022 · 0 comments
Open

LFS detects objects as “In Repo” that are not #20413

HermannDppes opened this issue Jul 19, 2022 · 0 comments

Comments

@HermannDppes
Copy link

HermannDppes commented Jul 19, 2022

Description

When in a Gitea repo, one may go to “Settings→LFS→Find pointer files” to see a list/table of LFS blob pointers about which Gitea knows something. The last three columns in that table are labelled “In Repo”, “Exists in Store” and “Accessible to User”. If documentation on their meaning exists, I have not found it, but I'm assuming the following:

  • In Repo: Is referenced by some commit in some branch of the repository
  • Exists in Store: Is present in the LFS store of Gitea, i.e. could be downloaded from the server when checking out the repo
  • Accessible to User: [actually, I have no idea]

I can however reliably create a situation where a file is present in the store and marked as “In Repo” that is not referenced in any commit present in the repo. (And we have at least one actual repository where that happened to one of our users naturally.) These files seem to be unnoticed by both the health check as well as the garbage collector.

When clicking “Find commits” there are “No Commits found for this LFS file”. When going through the revision of the repo with git ls-tree, the id of the LFS pointer file is not found (hence my claim that these are not present even in repos to large to check by hand).

How to reproduce

I have tested this while running a Linux with Bash on my client but I would assume that this takes only minimal or no changes to be run on other clients.

  1. Create a new repo in Gitea and make note of the remote access url, e.g. ssh://git@gitea.example.org:22/User/repo.git
  2. Make this script executable in some file, e.g. ./lfs-confusion.sh
    REMOTE_REPO=$1
    GIT_DIR=$(mktemp -d)
    cd $GIT_DIR
    git init .
    git checkout -b main
    git remote add gitea $REMOTE_REPO
    git lfs track "*.txt"
    echo "Hello, world" >hello.txt
    git add hello.txt
    git config user.name "A. Script"
    git config user.email "_@example.org"
    git commit -m "Ephemeral commit"
    git push --set-upstream -f gitea main
    rm .gitattributes
    git rm hello.txt
    echo "Hello, world" >hello.txt
    git add hello.txt
    git commit --amend -m "Eternal commit"
    git push -f
  3. Execute the script with the url as argument, e.g. $ ./lfs-confusion.sh ssh://git@gitea.example.org:22/User/repo.git

The result should be a repo which has only a single branch and only a single commit on that branch and only a single file in that commit where the file is not stored via LFS but under the LFS settings a file is listed as being “In Repo” (as well as “Exists in Store” and “Accessible to User”).

Gitea Version

1.16.9

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/HermannDppes/b3068c952aedb5210fdd6d6d8172cf88 (More extensive log to follow as soon as I find the time and patience to clean up the data I might not want to leak.)

Screenshots

single file in LFS settings, all three checkmarks set

Git Version

2.30.2

Operating System

Debian 10 (Buster)

How are you running Gitea?

From downloaded binary, started via systemd

Database

MySQL

Edits

  • Added

    and marked as “In Repo”

    in the second paragraph, as this somehow slipped by and is a rather important restriction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants