Cannot rebase via PR on a repository with git-lfs setup for a remote lfs server artifactory and no bitbucket support.

[James Hart]

My use case here is that I need to use LFS in a repository in an on premiss instance of bitbucket. The instance does not have lfs enable. The repository is using LFS configured to use a remote LFS artifactory.

In this configuration, when I have a pull request and attempt to rebase using PR-Booster I get the following:

PR-Booster-2019.08.12 / Git-2.16.5 / Bitbucket-5.16.11 / Linux-3.10.0-957.27.2.el7.x86_64-amd64
Exit=128 /usr/bin/git reset --hard --quiet e3b64e3bf445c8b159586ea467b10c81527f8ca6 --
git-lfs filter-process --skip: git-lfs: command not found
fatal: The remote end hung up unexpectedly

I think this is because the PR-Booster plugin has a modified configuration hard-coding the filter.lfs configuration with the ‘required’ keyword?

However since our instance doesn’t have git-lfs support the command isn’t there resulting in the command not found.

What I was expecting in this configuration is that the filter because a no-op as describe in the gitattribute documentation. But if PR-Booster is overriding the config for lfs driver with required it would explain this error.

Note this error is rebasing onto a branch that contains the .gittatributes file from a changeset without a line such as:

*.a filter=lfs diff=lfs merge=lfs -text

If I try to rebase where the changeset already exists in both branches with the gitattributes file I get a different error but I think it is related to the same issue except the git error doesn’t mention git-lfs:

‌

PR-Booster-2019.08.12 / Git-2.16.5 / Bitbucket-5.16.11 / Linux-3.10.0-957.27.2.el7.x86_64-amd64 
Exit=128 /usr/bin/git reset --hard --quiet e3b64e3bf445c8b159586ea467b10c81527f8ca6 --
error: Entry '.build' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'e3b64e3bf445c8b159586ea467b10c81527f8ca6'.

‌

I don’t administer this instance or can have admin permissions to the repository configuration in bittbucket. I can’t look at any configuration or run any configuration experiments for you .

If there is a workaround or configuration option for this use case please advise so I can pass the information along.

‌

[Julius Davies [bit-booster.com]]

‌

PR-Booster runs all of its “git-lfs” commands with the “--skip” argument. Basically PR-Booster, during its rebase, needs the “git-lfs” command to be available, but just to execute no-ops as part of the lfs process. If you can get a linux admin on that server to install “git-lfs” then everything should start working (lfs would still remain “disabled” on Bitbucket for the repository - it’s only PR-Booster’s attempt to run no-ops during the rebase where this “git-lfs” command needs to be available).

If your linux admins are allowed to install EPEL rpms, then simply typing “yum install git-lfs” should do the trick (for someone with root).

EPEL maintains a git-lfs RPM: https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/g/

‌

‌

‌

‌

‌

[James Hart]

That second error I showed about not uptodate. cannot merge is a secondary issue probably caused by the first error leaving the workspace in a bad state. We had to reset that PR-Booster clone space to solve that second problem. Maybe there is a secondary bug here, but the first error about git-lfs is the important one here.

Also, I confirmed if I change the gitattribute file to contain a custom driver name such as:

# Use lfs-custom as driver definition to workaround PR-Booster forced configuration when lfs isn't enabled on bitbucket server.
*.a filter=lfs-custom diff=lfs merge=lfs -text

That works around the initial issue that breaks the workspace with the git-lfs: command not found error during the rebase. It isn’t ideal though because all our developers need to now manually update their config files and remember to change any new gitattribute lines added by git lfs track.

‌

‌

[James Hart]

Thanks @Julius Davies [bit-booster.com] unfortunately I don’t think it will be easy to get the approval to side load git-lfs.

I think this use case needs to be supported and perhaps configurable on a per repo basis? Would it be reasonable to add a check box option such as ‘enable git-lfs confguration' that maybe defaults to on? I think my case to use Bitbucket + git-lfs but not the native Bitbucket lfs feature is probably less common.

‌