Skip to content
GitLab
Next
Open
Issue created by Manuel Bastuck@manuel.bastuck

Files not tracked with LFS when uploaded through the web interface

Summary

Uploading a file to be tracked with LFS via the web interface results in a file not tracked with LFS. This happens when the uploading user has no rights to push to the current branch (e.g. a Developer trying to upload to protected master) and, thus, a new branch is created automatically. The file is not tracked with LFS in this new branch and, therefore, neither in master when the Merge Request is accepted. It is not the case that just the "LFS"-tag is missing in the web interface: cloning the repository yields the following warning: Encountered 1 file(s) that should have been pointers, but weren't followed by a list of the files in question.

Creating a new branch manually and uploading the file there works as expected, i.e., the file is tracked with LFS.

Steps to reproduce

  1. Set up a project with a repository with LFS enabled.
  2. Set up LFS tracking for at least one file, e.g. git lfs track "*.pdf".
  3. Commit and push so that .gitattributes is visible in the master branch in the web interface.
  4. Invite a user as Developer.
  5. As this user, open the project (you see the master branch), click "+" and "Upload file". Leave default values and upload a file matching the LFS pattern specified in step (2), e.g. lfs-test.pdf.
  6. Check the newly (and automatically) created branch. The uploaded file is not tracked with LFS.
  7. Cross-check: create a branch manually and upload the file here the same way. It is tracked with LFS as expected.

Example Project

n/a

What is the current bug behavior?

Files matching LFS patterns are not tracked with LFS when they are uploaded with "Upload file" and a new branch is automatically created in that process.

What is the expected correct behavior?

The uploaded file should be tracked with LFS as it is (correctly) when a branch is created manually instead of automatically.

Relevant logs and/or screenshots

n/a

Output of checks

n/a

Results of GitLab environment info

self-managed, 13.10.0-ee

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Edited by Manuel Bastuck