{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":317045,"defaultBranch":"private","name":"git","ownerLogin":"peff","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2009-09-25T03:17:22.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/45925?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1717233140.0","currentOid":""},"activityList":{"items":[{"before":"49be485dabbfd030c37708d7cd7b5a84de86286f","after":"460a7f93240a91e9949822ed9d0fa117779b9593","ref":"refs/heads/jk/more-ps-leakfixes","pushedAt":"2024-06-04T10:05:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"sparse-checkout: free duplicate hashmap entries\n\nIn insert_recursive_pattern(), we create a new pattern_entry to insert\ninto the parent_hashmap. If we find that the same entry already exists\nin the hashmap, we skip adding the new one. But we forget to free the new\none, creating a leak.\n\nWe can fix it by cleaning up the discarded entry. It would probably be\npossible to avoid creating it in the first place, but it's non-trivial.\nWe'd have to define a \"keydata\" struct that lets us compare the existing\nentries to the broken-out fields. It's probably not worth the\ncomplexity, so we'll punt on that for now.\n\nThere is one subtlety here: our insertion is happening in a loop, with\neach iteration looking at the pattern we just inserted (hence the\n\"recursive\" in the name). So if we skip insertion, what do we look at?\n\nThe obvious answer is that we should remember the existing duplicate we\nfound and use that. But I _think_ in that case, we probably already have\nall of the recursive bits already (from when the original entry was\nadded). And so just breaking out of the loop would be correct. But I'm\nnot 100% sure on that; after all, the original leaky code could have\ndone the same break, but it didn't.\n\nSo I went with the \"obvious answer\" above, which has no chance of\nchanging the behavior aside from fixing the leak.\n\nWith this patch, t1091 can now be marked leak-free.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"sparse-checkout: free duplicate hashmap entries"}},{"before":"0ea751357a20295e8ebd634ae12c071f36a307ac","after":"08a612c15196223a0bc45984c3a21f6774ea6d13","ref":"refs/heads/jk/read-tree-content-merge-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"teach read-tree to do content-level merges [ci skip]\n\nRead-tree will resolve simple 3-way merges, such as a path\ntouched on one branch but not on the other. With\n--aggressive, it will also do some more complex merges, like\nboth sides adding the same content. But it always stops\nshort of actually merging content, leaving the unmerged\npaths in the index.\n\nOne can always use \"git merge-index git-merge-one-file -a\"\nto do a content-level merge of these paths. However, that\nhas two disadvantages:\n\n  1. It's slower, as we actually invoke merge-one-file for\n     each unmerged path, which in turns writes temporary\n     files to the filesystem.\n\n  2. It requires a working directory to store the merged\n     result. When working in a bare repository, this can be\n     inconvenient.\n\nInstead, let's have read-tree perform the content-level\nmerge in core. If it results in conflicts, read-tree can\nsimply punt and leave the unmerged entries in the index.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"teach read-tree to do content-level merges [ci skip]"}},{"before":"bb92d3262771e3b7d4a7714d0506c1269de7707f","after":"0d19498f8ae03cdf271e0dc3ffc5740b611ece88","ref":"refs/heads/jk/archive-reachability","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"t5000: drop tag to supposedly unreachable object\n\nWe try to create an unreachable commit, but test_commit will\nretain a tag pointing to it. Oops.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"t5000: drop tag to supposedly unreachable object"}},{"before":"4db88d75979ce435eebc92be7be67b511939dab2","after":"0ea823f02d9c3538805b66fea2ad77158c1ad565","ref":"refs/heads/jk/diff-max-depth","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"teach tree-diff a max-depth parameter\n\nWhen you are doing a tree-diff, there are basically two\noptions: do not recurse into subtrees at all, or recurse\nindefinitely.  While most callers would want to always\nrecurse and see full pathnames, some may want the efficiency\nof looking only at a particular level of the tree. This is\ncurrently easy to do for the top-level (just turn off\nrecursion), but you cannot say \"show me what changed in\nsubdir/, but do not recurse\".\n\nThis patch adds a max-depth parameter which is measured from\nthe closest pathspec match, so that you can do:\n\n  git log --raw --max-depth=1 a/b/c\n\nand see the contents of a/b/c/, but not those of a/b/c/d/\n(you would see the --raw entry for a/b/c/d in such a case).\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"teach tree-diff a max-depth parameter"}},{"before":"dab748e7290a199f644568aedc82dba00f375f75","after":"0ffd30b9f657929b0f92b5a57a3790f215b0bcbb","ref":"refs/heads/jk/blame-tree-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"add blame-tree command [ci skip]\n\nThis command shows the most recent modification to paths in\na tree. It does so by expanding the tree at a given commit,\ntaking note of the current state of each path, and then\nwalking backwards through history looking for commits where\neach path changed into its final sha1.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"add blame-tree command [ci skip]"}},{"before":"19ec0ade809f96dacbc6a8ab5b7631b0966e30b2","after":"1a1d52acb5819d022090d397604871fee51e1537","ref":"refs/heads/jk/hash-object-check-fsck-result","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"index_mem(): check return value of fsck_finish()\n\nThis would catch problems in blobs that were newly linked to git\nmetafiles (like .gitmodules) by a tree we are checking. We should add a\ntest.\n\nNote that fsck_finish() both checks the blobs and frees the memory. So\nin a short-circuit \"||\", we'd fail to do that cleanup if fsck_buffer()\nreports a problem. That's OK in this case because we die(). Maybe this\nshould stay as two separate conditionals.","shortMessageHtmlLink":"index_mem(): check return value of fsck_finish()"}},{"before":"21e5024460f79e339a8e954665ed6ab60ae506a0","after":"1b9bff30086c4ffe5f413c20ea5bae6ef13305ee","ref":"refs/heads/jk/symbolic-ref-no-symlinks","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"create_symref: drop support for writing symbolic links\n\nThe parent commit deprecated the writing of symbolic links\nfor symrefs.  Now that some time has passed, we can follow\nthrough by dropping the code.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"create_symref: drop support for writing symbolic links"}},{"before":"c1784d424af392d5bce850fb571612c6e88790f5","after":"1ba4d7de9d2e0851cc507d5c7f0d541b8160889b","ref":"refs/heads/jk/commits-notes-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"commit: allow editing notes in commit message editor\n\nOne workflow for git-notes is to informally keep a list of\nchanges from one version of a patch to another as the patch\nis modified via \"commit --amend\" and \"git rebase\". Often the\nmost convenient time for this is while editing the commit\nmessage, since you see it during amend, during \"rebase -i\"\nedit stops, and when \"rebase\" finds a conflict.\n\nThis patch adds a \"--notes\" option which displays existing\nnotes in the commit editor (in the case of --amend), and\nextracts new notes from the editor message to add to the\nnewly created commit.\n\nThe feature is activated only for interactive edits, so \"-F\"\nand \"-m\" messages are safe from munging.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"commit: allow editing notes in commit message editor"}},{"before":"1d4a7454fa83fd8a5f747f1b642c34451cc08a31","after":"240957a0bd95a16b43bbd753b3276a23d8d3b042","ref":"refs/heads/jk/signal-masks-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"sigchain: mask out common signals\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"sigchain: mask out common signals"}},{"before":"b506441c13ca946d21ba53f7f0b82511c29859bc","after":"277789c1433aa34f13d52faadfb294c7a55a7484","ref":"refs/heads/jk/textconv-utf16","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"diff: enable autoencode by default\n\nThis turns on auto-encode whenever textconv is on and the\n--binary option has not been used.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"diff: enable autoencode by default"}},{"before":"ae564697b650f2aa0d2ee730666a92df868909a1","after":"2d1b2f341407dda2a849f3e53b4d0ad471bfc702","ref":"refs/heads/jk/exclude-int-max","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"dir.c: skip .gitignore, etc larger than INT_MAX\n\nWe use add_patterns() to read .gitignore, .git/info/exclude, etc, as\nwell as other pattern-like files like sparse-checkout. The parser for\nthese uses an \"int\" as an index, meaning that files over 2GB will\ngenerally cause signed integer overflow and out-of-bounds access.\n\nThis is unlikely to happen in any real files, but we do read .gitignore\nfiles from the tree. A malicious tree could cause an out-of-bounds read\nand segfault (we also write NULs over newlines, so in theory it could be\nan out-of-bounds write, too, but as we go char-by-char, the first thing\nthat happens is trying to read a negative 2GB offset).\n\nWe could fix the most obvious issue by replacing one \"int\" with a\n\"size_t\". But there are tons of \"int\" sprinkled throughout this code for\nthings like pattern lengths, number of patterns, and so on. Since nobody\nwould actually want a 2GB .gitignore file, an easy defensive measure is\nto just refuse to parse them.\n\nThe \"int\" in question is in add_patterns_from_buffer(), so we could\ncatch it there. But by putting the checks in its two callers, we can\nproduce more useful error messages.","shortMessageHtmlLink":"dir.c: skip .gitignore, etc larger than INT_MAX"}},{"before":"12b06b933ddf88c4046bf47ea468ec87bc765eef","after":"34c2183100776b6a589209e59af17c4e4a0d775e","ref":"refs/heads/jk/adjustable-windows","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"pack-objects: trace adjustable window stats for each object\n\nThis trace outputs the slot and byte numbers at which we found the delta\ncandidate that we end up using in the packfile output. If run without\nany pack.windowSlotLimit or pack.windowByteLimit, that can give a sense\nof what good values are for those config options (at least for this\nrepository).\n\nRunning a full window=200 repack of the torvalds/linux fork network with\nGIT_TRACE_DELTA yields a 3GB trace file, from which we can gather some\npercentile statistics on the slot numbers:\n\n       p50: 1\n       p75: 2\n       p90: 8\n       p98: 62\n       p99: 99\n       max: 200\n\nSo we usually find our best candidate quite early on. Half the time it's\nthe first one we try, and 90% of the time it's in the first 8. Of course\nthere's a tail of cases that require going to 100 or further, but those\nare the minority. That explains why limiting to slots=20 worked\nreasonably well.\n\nAnd here's the same run for byte statistics:\n\n       p50: 3462\n       p75: 16464\n       p90: 97644\n       p98: 708408\n       p99: 1592577\n       max: 265848594\n\nSetting the byte limit at 1m means we'll find the same candidates in\n98-99% of cases. But of course the more bytes we look through to find\ncandidates, the bigger the object, and thus the more we have to gain by\nactually finding a delta. So even though our limit excludes less than 2%\nof the deltas we'd otherwise found, we still saw our resulting pack size\nincrease by several percent.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"pack-objects: trace adjustable window stats for each object"}},{"before":"db3baf14f0ab051aaa02246bf47a7c1fdd30cdc8","after":"382cf52798b39364534a5dcd93eb463c99f50d1f","ref":"refs/heads/jk/binary-diff-size-mode","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"diff: ignore mode in binary size optimization\n\nThis makes add/delete work.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"diff: ignore mode in binary size optimization"}},{"before":"56205b75fa07dec7acfd02f67a4a5fb34979115e","after":"382daf4d30617f6ae73466ce441cf7d7397d095a","ref":"refs/heads/jk/export-symlink","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"fix?\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"fix?"}},{"before":"21b5f75757973a86301f3ab1c61eaa27cec2adde","after":"38ed1eb6104afbe7fd944732a5b3783d2902eea3","ref":"refs/heads/jk/pathspec-trie-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"tree-diff: use pathspec tries\n\nThe tree-diff currently matches each pathspec against every\nentry of the tree. For the common case of a handful of\npathspecs, this is not a big deal. However, if you have a\nlarge number of pathspecs, it gets noticeably slow.\n\nNow that we have the pathspec_trie optimization, we can do\nmuch better (at least for simple cases without wildcards).\nHere are numbers for running \"git rev-list\" with limiting\npathspecs of varying sizes, both before and after this\npatch:\n\nTest                 origin              HEAD\n---------------------------------------------------------------\n4001.2: size=1       0.12(0.11+0.00)     0.12(0.12+0.00) +0.0%\n4001.3: size=2       0.17(0.16+0.00)     0.16(0.15+0.01) -5.9%\n4001.4: size=4       0.17(0.17+0.00)     0.17(0.17+0.00) +0.0%\n4001.5: size=8       0.21(0.20+0.00)     0.20(0.20+0.00) -4.8%\n4001.6: size=16      0.25(0.24+0.00)     0.21(0.20+0.00) -16.0%\n4001.7: size=32      0.31(0.31+0.00)     0.21(0.20+0.00) -32.3%\n4001.8: size=64      0.43(0.41+0.01)     0.21(0.21+0.00) -51.2%\n4001.9: size=128     0.73(0.72+0.00)     0.22(0.21+0.00) -69.9%\n4001.10: size=256    2.02(2.02+0.00)     0.37(0.36+0.00) -81.7%\n4001.11: size=512    6.78(6.78+0.00)     0.64(0.64+0.00) -90.6%\n4001.12: size=1024   23.67(23.67+0.02)   1.22(1.20+0.01) -94.8%\n\nFor small pathspecs, we produce no real difference (which is\ngood; we know we are asymptotically better, but we have not\nregressed our constant factor). Between 16 and 32 pathspecs we\nstart to see some small improvement, and the benefit keeps\ngrowing with the number of pathspecs.\n\nObviously these large-pathspec cases are unusual. But you\nmight use them, for example, if the pathspecs were generated\nprogramatically (e.g., if you want the history of all files\nthat are in Documentation/ _now_, not what was historically\never there, you would expand the pathspec at the current\ntree, and feed the result to rev-list).\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"tree-diff: use pathspec tries"}},{"before":"29826e83143ef5d98245b81b8b37a6a4789c6432","after":"3927dd33b49c7f4a2979f5a71a44ab5d6b42bcdb","ref":"refs/heads/jk/trace-stdin","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"run-command: terrible hack for loading config\n\nIt's not safe to look at config before we've done\nsetup_git_directory(), as we may pollute the results of a\nlater call. This is a hack because:\n\n  1. we just silently disable this feature in this case (!)\n\n  2. is_bare_repository_cfg is probably not the best way to\n     know whether we've done setup or not.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"run-command: terrible hack for loading config"}},{"before":"55e7d197a2858915bed2e4b12d96d890c74d093c","after":"3b5fadc4dae3f6b49911bc87b5fb5a41af81314c","ref":"refs/heads/private","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"Merge branch 'jk/xdiff-hardening' into HEAD\n\n* jk/xdiff-hardening:\n  xdiff: drop bdiffparam_t\n  xdiff: convert size variables to size_t\n  xdiff: use st_* helper functions for allocations","shortMessageHtmlLink":"Merge branch 'jk/xdiff-hardening' into HEAD"}},{"before":"3955def867530ade9774379b79a427ebfd4666d2","after":"42714b36efc3153e0da96c959528224236381b7b","ref":"refs/heads/jk/test-seq-format","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"teach test_seq a -f option\n\nWith some example conversions. Note that some prefer that the newline is\nimplied, and some would prefer that it can be supressed.","shortMessageHtmlLink":"teach test_seq a -f option"}},{"before":"77f7c3f9d8ea93dcb0b2673b4f463ee684b2693b","after":"42c8232b3ccd36c854ef8fe091dcc8110e42df42","ref":"refs/heads/jk/dumpstat-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"zeromq dumpstat implementation\n\nThis tries to do as little as possible on top of zeromq,\nwhich might not work. It sends an \"id\" field with each\nmessage to keep some state. Probably this should be\ninherited through the environment.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"zeromq dumpstat implementation"}},{"before":"a5ccb69d72275179956ab0c12f6ee5e68e86c3c3","after":"44f511eec33b8e37fe3a810ad5e55f9dc69cab86","ref":"refs/heads/jk/git-path-unsafe","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"drop git_path()","shortMessageHtmlLink":"drop git_path()"}},{"before":"523b919c22c5a67190d7d78a26751297062970bd","after":"46124c1ec257f59b5b9c9e796b93d0e0cbaa163d","ref":"refs/heads/jk/object-info-round-trip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"allow content-limit\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"allow content-limit"}},{"before":"460a7f93240a91e9949822ed9d0fa117779b9593","after":"49be485dabbfd030c37708d7cd7b5a84de86286f","ref":"refs/heads/jk/more-ps-leakfixes","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"push","commitsCount":29,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"builtin/blame: fix leaking ignore revs files\n\nWhen parsing the blame configuration we add \"blame.ignoreRevsFile\"\nconfigs to a string list. This string list is declared as with `NODUP`,\nand thus we hand over the allocated string to that list. We eventually\nend up calling `string_list_clear()` on that list, but due to it being\ndeclared as `NODUP` we will not release the associated strings and thus\nleak memory.\n\nFix this issue by setting up the list as `DUP` instead and free the\nconfig string after insertion.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>","shortMessageHtmlLink":"builtin/blame: fix leaking ignore revs files"}},{"before":"d687b20e1e61c55505b3fe65959f378189f77313","after":"4a063f1c290036dc0e7a80bffb9d46ab698e6985","ref":"refs/heads/jk/oidmap-clear","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"oidmap: drop pointer check from clear\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"oidmap: drop pointer check from clear"}},{"before":"a205d1d42580dfd3eed86096f58b95fa82fc4775","after":"4e5df5556f010b2b48798a3861d51e1138b2b7b3","ref":"refs/heads/jk/contains-merge-base-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"perf: add tests for tag --contains\n\nThese tests can demonstrate the changes in \"tag --contains\"\nspeed over time. The interesting points in history are:\n\n  - pre-ffc4b80, where we used a series of N merge-base\n    traversals\n\n  - ffc4b80 up to the current master, where we moved to a\n    single depth-first traversal\n\n  - the previous commit, where we moved from depth-first to\n    a multi-tip merge-base\n\nThe interesting cases to measure are:\n\n  - checking which tags contain a recent commit (we use\n    HEAD~100 here)\n\n  - checking which tags contain a very ancient commit (we\n    use the last commit output by rev-list)\n\n  - checking which tags contain a commit in the middle (we\n    use HEAD~5000, which goes back 5 years in git.git)\n\n  - all of the above, but instead of looking at all commits,\n    considering only recent ones (we pick the most recent\n    tag by its tagger date)\n\nHere are the timings for git.git:\n\n  Test                               ffc4b80^          origin/master             HEAD\n  -----------------------------------------------------------------------------------------------------\n  7100.3: contains recent/all        3.53(3.51+0.00)   0.33(0.31+0.01) -90.7%    0.35(0.33+0.02) -90.1%\n  7100.4: contains recent/v2.12.0    0.09(0.08+0.00)   0.33(0.32+0.00) +266.7%   0.08(0.08+0.00) -11.1%\n  7100.5: contains old/all           2.11(2.10+0.00)   0.26(0.25+0.00) -87.7%    0.35(0.33+0.01) -83.4%\n  7100.6: contains old/v2.12.0       0.33(0.32+0.01)   0.25(0.24+0.00) -24.2%    0.33(0.32+0.00) +0.0%\n  7100.7: contains ancient/all       1.39(1.37+0.01)   0.16(0.15+0.00) -88.5%    0.35(0.34+0.00) -74.8%\n  7100.8: contains ancient/v2.12.0   0.34(0.32+0.01)   0.11(0.10+0.00) -67.6%    0.34(0.33+0.00) +0.0%\n\nYou can see that ffc4b80 vastly improved the normal case of\nchecking all tags. This is because we avoid walking over the\nsame parts of history over and over. However, when looking\nonly for a recent tag (v2.12.0 in these tests), it sometimes\nperforms much worse than the original. This is not\nsurprising. For a merge-base solution, we can quit when we\nhit history shared between the contained commit and the tag.\nFor ffc4b80's depth-first approach, we typically go all the\nway to the roots before backtracking. For the ancient/v2.0.1\ncase, that's not a big deal, because the merge base requires\nus doing that anyway. But for recent/v2.0.1, the merge-base\nanswer should involve only recent history.\n\nThe new traversal code performs about as well as the\ndepth-first code in the normal case, but fixes the\nregression in the recent/v2.0.1 case.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"perf: add tests for tag --contains"}},{"before":"84afa7533d2adba9d48953942597bf50528be82b","after":"503ce85a3a1529f9782a0229c7cbb48c814748db","ref":"refs/heads/jk/revs-commits-prio-queue","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"pack-objects: release rev_info as appropriate\n\nThese seem to cause leaks with the prio_queue, but really, I'm surprised\nit wasn't doing so before (I guess because we consumed everything in the\nrevs->commits list?). But this should probably be a preparatory patch.","shortMessageHtmlLink":"pack-objects: release rev_info as appropriate"}},{"before":"34119e974ec5fb139298f6645e47b01eaf59c49c","after":"52902fd431b144f1991bdb51004f9784f6c8b871","ref":"refs/heads/jk/time-negative-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"extra warning hack\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"extra warning hack"}},{"before":"4e0b42ed51423e32497814456577267fb5bdc34b","after":"590508a55fe5ab6581965eeae15fd34915cdc197","ref":"refs/heads/jk/credential-interactive","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"wip\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"wip"}},{"before":"3ed025fa2c85b1a059bae313bf659dc7c6b8012b","after":"593c83bb24343b8171d8cfb6b0831d9be13210d5","ref":"refs/heads/jk/pager-in-use-careful","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"pager_in_use: make sure output is still going to pager\n\nWhen we start a pager, we set GIT_PAGER_IN_USE=1 in the\nenvironment. This lets sub-processes know that even though\nisatty(1) is not true, it is because it is connected to a\npager (and we should still turn on human-readable niceties\nlike auto-color).\n\nUnfortunately, this is too inclusive for scripts which\ninvoke git sub-programs with their stdout going somewhere\nelse. For example, if you run \"git -p pull rebase\", git-pull\nwill invoke \"git rebase\", which invokes:\n\n  git format-patch ... >rebased-patches\n\nThis format-patch process knows that its stdout is not a\ntty, but because of GIT_PAGER_IN_USE it assumes this is\nbecause stdout is going to a pager. As a result, it writes\ncolorized output, and the matching \"git am\" invocation\nchokes on it, causing the rebase to fail.\n\nWe could work around this by passing \"--no-color\" to\nformat-patch, or by removing GIT_PAGER_IN_USE from the\nenvironment. But we should not have to do so; format-patch\nshould be able to realize that even though GIT_PAGER_IN_USE\nis set, its stdout is not actually going to that pager.\n\nFor this simple case, format-patch could see that its output\nis not even a pipe. But that would not catch a case like:\n\n  git format-patch | some-program >rebased-patches\n\nwhere it cannot distinguish between the pipe to the pager\nand the pipe to some-program.\n\nThis patch solves it by actually noting the inode of the\npipe to the pager in the environment, which readers of\nGIT_PAGER_IN_USE can check against their stdout. This\ntechnically makes GIT_PAGER_IN_USE redundant (we can just\ncheck the new GIT_PAGER_PIPE_ID), but we keep using both\nvariables for compatibility with external scripts:\n\n  - scripts which check GIT_PAGER_IN_USE can continue to do\n    so, and will just ignore the new pipe-id variable.\n    Meaning they may accidentally turn on colors if their\n    output is redirected to a file, but that is the same as\n    today and we cannot fix that. We do not actively break\n    them from showing colors when their stdout _does_ go to\n    the pager.\n\n  - scripts which set GIT_PAGER_IN_USE but not\n    GIT_PAGER_PIPE_ID will continue to turn on colorization\n    for git sub-commands (again, they do not benefit from\n    the new code, but we are not making anything worse).\n\nThe inode-retrieval code itself is abstracted into compat/,\nas different platforms may represent the pipe id\ndifferently. These ids do not need to be portable across\nsystems, only within processes on the same system.\n\nNote that there is an existing test in t7006 which tests for\nthe exact _opposite_ of what we are trying to achieve\n(namely, that GIT_PAGER_IN_USE does _not_ cause us to write\ncolors to a random file). This test comes from a battery of\ntests added by 60b6e22 (tests: Add tests for automatic use\nof pager, 2010-02-19), and I think is simply misguided, as\nevidenced by the real \"git pull\" bug above. If you want to\nensure colors in a file, you do it with \"--color\", not by\npretending you have a pager.\n\nRather than delete the test, though, we simply re-title it\nhere. It actually makes a good check of the \"scripts which\nset PAGER_IN_USE but not PAGER_PIPE_ID\" historical\ncompatibility mentioned above.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"pager_in_use: make sure output is still going to pager"}},{"before":"ffae497e33ce9b1ecadd72c269360f646de7c41f","after":"5b856da45df2322be6890a653dc64241368c7e48","ref":"refs/heads/jk/reencode-size-t-wip","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"utf8: use size_t\n\nThese were rebased onto upstream patches that include an\noverflow-checking cast. We should get rid of that cast now.\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"utf8: use size_t"}},{"before":"d246427a3ec00e261a3ee5f5376729b02e8e936b","after":"629cf658669c5de02eb08e59b5de2e77a0176ba2","ref":"refs/heads/jk/bitmap-corruption","pushedAt":"2024-06-03T23:25:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"peff","name":"Jeff King","path":"/peff","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45925?s=80&v=4"},"commit":{"message":"wip -- better protection against corruption\n\nSigned-off-by: Jeff King <peff@peff.net>","shortMessageHtmlLink":"wip -- better protection against corruption"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEW92uPgA","startCursor":null,"endCursor":null}},"title":"Activity · peff/git"}