Closed
Description
- Gitea version (or commit ref): 1.10.0+dev-156-g8101d803e
- Git version: 2.22.0, though doesn't matter
- Operating system: Linux, though doesn't matter
- Can you reproduce the bug at https://try.gitea.io:
No (try.gitea.io is down), but I can reproduce it on https://gitea.com - Log gist:
$ git clone [email protected]:slonopotamus/gitea-blog.git
Cloning into 'gitea-blog'...
remote: Enumerating objects: 777, done.
remote: Counting objects: 100% (777/777), done.
remote: Compressing objects: 100% (343/343), done.
remote: Total 777 (delta 318), reused 726 (delta 299)
Receiving objects: 100% (777/777), 4.26 MiB | 1.46 MiB/s, done.
Resolving deltas: 100% (318/318), done.
$ cd gitea-blog
$ GIT_TRACE=1 git lfs lock Makefile
23:49:19.390102 git.c:704 trace: exec: git-lfs lock Makefile
23:49:19.390122 run-command.c:663 trace: run_command: git-lfs lock Makefile
23:49:19.392307 trace git-lfs: exec: git 'version'
23:49:19.393810 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:19.395162 trace git-lfs: exec: git 'config' '-l'
23:49:19.395913 trace git-lfs: run_command: ssh -- [email protected] git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:20.215639 trace git-lfs: HTTP: POST https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:21.521682 trace git-lfs: HTTP: 201
23:49:21.521743 trace git-lfs: HTTP: {"lock":{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21.392551447Z","owner":{"name":"slonopotamus"}}}
Locked Makefile
23:49:21.523013 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:21.523026 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:21.523060 trace git-lfs: filepathfilter: accepting "tmp"
$ GIT_TRACE=1 git lfs locks
23:49:24.582212 git.c:704 trace: exec: git-lfs locks
23:49:24.582235 run-command.c:663 trace: run_command: git-lfs locks
23:49:24.584455 trace git-lfs: exec: git 'version'
23:49:24.585256 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:24.586718 trace git-lfs: exec: git 'config' '-l'
23:49:24.587855 trace git-lfs: run_command: ssh -- [email protected] git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:25.396155 trace git-lfs: HTTP: GET https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:26.614518 trace git-lfs: HTTP: 200
23:49:26.614583 trace git-lfs: HTTP: {"locks":[{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21Z","owner":{"name":"slonopotamus"}}]}
Makefile slonopotamus ID:2
23:49:26.614832 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:26.614843 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:26.614875 trace git-lfs: filepathfilter: accepting "tmp"
Description
Look at "locked_at" timestamps. When lock it just created, Gitea returns timestamp with nanosecond precision: 2019-08-14T20:49:21.392551447Z
. But when I am listing locks later, timestamp only has second precision: 2019-08-14T20:49:21Z
Expected: lock is always returned with same timestamp precision via LFS API. Also, LFS protocol spec clearly says that timestamp needs to have second precision.
P.S. If this bug came with code from lfs-test-server, please tell me so I open a bugreport there too.