[BUG] Blobless clones don't work because .gitconfig isn't used for SSH clients #869
- v1.21 https://github.com/go-gitea/gitea/pull/25331
- v1.20 https://github.com/go-gitea/gitea/pull/25347
- Can you reproduce the problem on Forgejo Next?
I think this requires access to the server itself to reproduce
- Forgejo version (or commit ref): 1.19.3
- Git version: 2.39.2
- Operating system: Linux
- Database (use
- How are you running Forgejo?
I'm running the binary release for amd64 in a systemwide installation, as described in https://forgejo.org/docs/v1.20/admin/installation/#installation-from-binary
Blobless clones (
git clone --filter=blob:none ...) didn't work (
warning: filtering not recognized by server, ignoring), even though both
[uploadpack] allowfilter = true allowAnySHA1InWant = true
On the server, I ran
strings /proc/$(pidof git)/environ | grep HOME (while the git clone operation of the client was running) and it printed
I did not set
[Git] HOME_PATH in the app.ini, so it defaults to
%(APP_DATA_PATH)s/home, which should be
So in this case obviously $FORGEJO_WORK_DIR wasn't set, even though the
forgejo web process has it set correctly.
The problem appears to be that the entries that forgejo generates in
/home/git/.ssh/authorized_keys look like:
command="/usr/local/bin/forgejo --config=/etc/forgejo/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa AAAA....
So forgejo is called with the path to the config, but without setting
--work-path, so the Git HOME_PATH that forgejo generates is wrong.
So you should generate the authorized_keys entries in a way that also sets
-w), and ideally you should support setting the work path in the app.ini (and do set it when generating it in the web-based installation step), so it doesn't have to be specified on commandline all the time, see also forgejo/discussions#28
Use a systemwide forgejo installation (or any where
$FORGEJO_WORK_DIR is explicitly set, and you haven't explicitly configured
[Git] HOME_PATH in the app.ini) and try to clone a repo bloblessly from it, i.e. with
git clone HOME=/usr/local/bin/data/home git@yourhost:foo/bar.git, note that while cloning generally works, it will do a full clone and show this message at the beginning:
warning: filtering not recognized by server, ignoring
BTW, explicitly setting
[git] HOME_PATH = /home/git
HOME_PATH = /var/lib/forgejo/data/home) in the app.ini works around this problem - just in case anyone else runs into this before it's fixed..
I think this should be fixed before the next release.
[git] section in
app.ini was refactored in v1.20 but I suspect this particular problem persists. I see you have linked this issue to Gitea as well and maybe there will be more input there.
I finally got around to test 1.20rc0, and to my big surprise the issue seems to be fixed?!
$ strings /proc/$(pidof git)/environ | grep HOME HOME=/var/lib/forgejo/data/home
The app.ini (that apparently is modified by
forgejo migrate, or when first starting a new version?) now under server contains
APP_DATA_PATH=/var/lib/forgejo/data, which I guess is used to set those paths.
Weird I've never seen that mentioned in the chat or in https://github.com/go-gitea/gitea/issues/24222#issuecomment-1595599546 or forgejo/discussions#28
Of course, if (as suggested in the official installation instructions of both gitea and forgejo) /etc/forgejo/app.ini is set to readonly after the initial installation, upgrading to 1.20 will not automatically fix this bug for users.
But it might suffice to adapt the migration guide to tell people to make the app.ini writable before upgrading (and running
forgejo -w /path/to/working_dir -c /path/to/app.ini migrate)?
Also, how come https://forgejo.org/docs/v1.20/admin/upgrade/ doesn't even mention
Also, how come https://forgejo.org/docs/v1.20/admin/upgrade/ doesn't even mention forgejo migrate
The migration implicitly happens when the newer version is started. I suspect very few people use
forgejo migrate and I would not be surprised if it does not do exactly the same thing.
forgejo doctor can be run after to identify / fix issues. If there is a difficult situation discovered that cannot be resolved, the Forgejo instance is restored from the backup done before the upgrade.
I explicitly had to call
forgejo migrate for the database to be migrated to the newer version.
forgejo doctor complained about wrong DB version and suggested running
gitea migrate (you should change that to
I explicitly had to call forgejo migrate for the database to be migrated to the newer version.
I can't reproduce that issue, no idea what went wrong, maybe I ran
forgejo doctor before running
forgejo web, so the migration hadn't run yet? Not sure anymore (and unfortunately I didn't make a backup before the update, because it was just a test repo).
Still, that warning in
forgejo doctor should recommend calling
forgejo migrate, not
gitea migrate :)
Still, that warning in forgejo doctor should recommend calling forgejo migrate, not gitea migrate :)
This was fixed with #871 yesterday.
The ideal solution would be for the Forgejo to be a white label software with the theming (name, logo, etc.) cleanly separated in a well documented directory. Eventually the
forgejo-branding feature branch will make it possible to do that but there is a long way to go before it happens.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?