{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":790420856,"defaultBranch":"main","name":"git-tools","ownerLogin":"makenotion","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2024-04-22T21:06:31.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/4792552?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1713820354.0","currentOid":""},"activityList":{"items":[{"before":"faba1cd26b8741ccf781bd7ed5e296a06b3dec86","after":"a1c20040568feb55b04b045242e79b4ef1bfaf27","ref":"refs/heads/main","pushedAt":"2024-04-22T21:17:56.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"benjaminjkraft","name":"Ben Kraft","path":"/benjaminjkraft","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/111238?s=80&v=4"},"commit":{"message":"Don't detect copies/renames in restore-mtime (#1)\n\nThe big benefit of this is in a [blobless clone], where it lets you\r\navoid downloading all the blobs (which you shouldn't need just to know\r\n_whether_ a file changed). But it's probably a perf win always: it makes\r\n`git log` do a bit less work. (And it should always be at least as\r\ncorrect: for the purposes of mtime restoration, a move/copy should count\r\nas a modification -- your build tool should assume the file must be\r\nrebuilt in its new location.)\r\n\r\n[blobless clone]: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/\r\n\r\nI tested this by:\r\n- make a clone of a large repo (`git clone --filter=blob:none ...`)\r\n- run `git restore-mtime` in the repo; after this change it takes ~10s\r\n\r\nBefore this change, in a blobless repo, it would loop for a very long\r\ntime with periodic log lines indicating it was fetching more blobs:\r\n```\r\nremote: Enumerating objects: 2, done.\r\nremote: Counting objects: 100% (1/1), done.\r\nReceiving objects: 100% (2/2), 6.75 KiB | 2.25 MiB/s, done.\r\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 1\r\n```","shortMessageHtmlLink":"Don't detect copies/renames in restore-mtime (#1)"}},{"before":null,"after":"b416dff5a02b73f2cedccb97d1afff0130bfe20d","ref":"refs/heads/benkraft.fix-blobless","pushedAt":"2024-04-22T21:12:34.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"benjaminjkraft","name":"Ben Kraft","path":"/benjaminjkraft","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/111238?s=80&v=4"},"commit":{"message":"Don't detect copies/renames in restore-mtime\n\nThe big benefit of this is in a [blobless clone], where it lets you\navoid downloading all the blobs (which you shouldn't need just to know\n_whether_ a file changed). But it's probably a perf win always: it makes\n`git log` do a bit less work. (And it should always be at least as\ncorrect: for the purposes of mtime restoration, a move/copy should count\nas a modification -- your build tool should assume the file must be\nrebuilt in its new location.)\n\n[blobless clone]: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/\n\nI tested this by:\n- make a clone of a large repo (`git clone --filter=blob:none ...`)\n- run `git restore-mtime` in the repo; after this change it takes ~10s\n\nBefore this change, in a blobless repo, it would loop for a very long\ntime with periodic log lines indicating it was fetching more blobs:\n```\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (1/1), done.\nReceiving objects: 100% (2/2), 6.75 KiB | 2.25 MiB/s, done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 1\n```","shortMessageHtmlLink":"Don't detect copies/renames in restore-mtime"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEN3IA4wA","startCursor":null,"endCursor":null}},"title":"Activity ยท makenotion/git-tools"}