- 综合排序
- 最热优先
- 最新优先
- 来自专栏光变
Gradle Unable to blame file
. > Unable to blame file src/main/java/xxxxxtMapper.java * Try: Run with --info or --debug option to org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40) Caused by: java.lang.IllegalStateException: Unable to blame file src/main/java/xxxxxtMapper.java at org.sonar.plugins.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java WindowCursor.java:145) at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:229) at org.eclipse.jgit.blame.BlameGenerator.push org.eclipse.jgit.api.BlameCommand.call(BlameCommand.java:217) at org.sonar.plugins.scm.git.JGitBlameCommand.blame
74910发布于 2018-08-07 - 来自专栏iSharkFly
IntelliJ IDEA 如何显示 git blame
git blame 用来追溯一个指定文件的历史修改记录。 它能显示任何文件中每行最后一次修改的提交记录。 简单点来说你可以知道这行代码是什么时候提交的，是谁提交的。 然后选择第一个：annotate with git blame 就可以显示文件的提交历史记录了。 显示的结果如下： 是不是很容易就找到这个是谁在什么时候修改的了。 https://www.ossez.com/t/intellij-idea-git-blame/13901
6K40编辑于 2022-03-06 - 来自专栏码农桃花源
写一个 panic blame 机器人
再执行 git blame 看看究竟是谁写的，再去群里 @ 他进行处理。但很多情况下是这些 panic 是由脏数据导致的，发生的也不频繁，并且 panic 被 recover 住了，所以也不太着急。 像前面提到的 panic 报警发生的多了，我“查日志，定位到代码提交人再通知他处理”的事情多了之后，就想能不能写一个 panic blame 机器人来做这件事。这样就能省不少事，而且还显得那么优雅。 local/go/src/runtime/panic.go:679，也就是 runtime 里的 gopanic 函数；下一行就是真正引起 panic 的使用空指针的那一行代码，这是罪魁祸首，panic blame 实现一个 panic blame 机器人比较简单，但考虑服务稳定性的话，还是有一些点要注意的。
44530发布于 2021-02-01 - 来自专栏腾讯技术工程官方号的专栏
【git重案组】如何逃避git blame的追踪？
导语：程序员的血腥复仇——论如何偷偷修改代码而不被别人发现... 背景介绍 上周笔者在工作中发现git仓库出现了一个奇怪的问题，master分支中某文件的一次commit丢失掉了，但diff中没有任何记录，这让笔者一度怀疑是git或者code平台自己出了问题。 在code平台一条条比对后发现变动发生在feature分支merge master分支之后。 原本SHA为8950d的edit.vue 文件最近一次修改是在一周前。 在merge之后该文件回滚到了两周前。 通过查询该文件的comm
1.4K50发布于 2019-09-10 给 AI 智能体装了个“黑匣子”，3 秒定位谁该背锅
所以我给 AI 智能体装了一个 “黑匣子” —— Agent Blame-Finder。它能在 3 秒钟内告诉你：锅在谁那儿。它能干什么？ 一条命令，直接出结果：$ blame-finder blame incident-abc123 甩锅结果：Coder-Agent 原因：输入的需求没问题，但输出的代码不符合预期 责任链： ✅ PM-Agent 没有 Blame-Finder有 Blame-Finder手动翻几小时日志blame-finder blame <id> 秒出结果“大概是 Agent X 的锅” 扯皮加密证据，无法抵赖没有审计记录JEP 收据，不可篡改因果关系断裂完整的 task_based_on 决策树它就是 AI 智能体世界的 git blame。 ） 一键导出 PDF/HTML 甩锅报告现在就试试pip install agent-blame-finder然后启动可视化面板：blame-finder dashboard你会看到一个像 Git 图一样的因果树
11910编辑于 2026-04-08- 来自专栏python3
Python十讲 - 第二讲：变量和基础
# 加引号是为了区分空格 # 也可以指定去除的字符 name = '**blame kidd*' print(name.strip('*')) # 去除字符串首尾的* 结果：blame kidd' print(name.capitalize()) 结果：Blame kidd 6. title：非字母隔开的每个部分的首字母大写 name = 'blame kidd' print(name.title ()) 结果：Blame Kidd 7. center：字符串居中，前后填充自定义的字符 name = 'blame kidd' print(name.center(20, '*')) 结果：***** blame kidd***** 8. upper：字符串全部大写；；lower：字符串全部小写 name = 'Blame Kidd' print(name.upper()) 结果：BLAME KIDD 9. swapcase：大小写转换 name = 'BlaMe kiDd' print(name.swapcase()) 结果：bLAmE KIdD 10.
65310发布于 2020-01-21 - 来自专栏stcnb
dotnet test
] [--blame-crash] [--blame-crash-dump-type <DUMP_TYPE>] [--blame-crash-collect-always] [--blame-hang 意味着 --blame。 --blame-crash-dump-type <DUMP_TYPE> （自 .NET 5.0 SDK 起可用） 要收集的故障转储的类型。 意味着 --blame-crash。 意味着 --blame-hang。 意味着 --blame 和 --blame-hang。 -c|--configuration <CONFIGURATION> 定义生成配置。
3.9K20编辑于 2022-01-05 - 来自专栏大猪的笔记
git历史查看工具
import os import subprocess import sys filename = sys.argv[1] find_text = sys.argv[2] try: is_blame = sys.argv[3] except: is_blame = False def cmd(cmdstr): return subprocess.check_output(cmdstr def reset(self): self.q = [] queue = Queue(2 * near_lines + 1) queue.key = find_text def blame (): queue.pos = 65535 ret = cmd("git blame {}".format(filename)).decode("utf-8").split("\n") : blame() else: history()
1.2K20发布于 2019-11-22 - 来自专栏萝卜要加油
Git 中你可能不知道的魔法文件
.git-blame-ignore-revs .git-blame-ignore-revs 文件用来列出 git blame 应该跳过的提交。 .git-blame-ignore-revs。 .git-blame-ignore-revs 文件。 这个文件解决了一个经典问题：对整个代码库运行格式化工具之后，git blame 会变得毫无用处。有了这个文件，blame 就会跳过那些格式化提交，显示真正的代码逻辑作者。 文档: https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt [12]husky
13710编辑于 2026-03-04 - 来自专栏林德熙的博客
VisualStudio 自定义外部命令
例如添加内容是打开 git 、打开资源管理器、打开 git blame des Title Command Arguments Initial directory 在此仓库运行 Git Bash C:\ 在 VisualStudio 添加 Blame 在 VisualStudio ，我看到了自带的 Blame 很烂，于是如何在 VisualStudio 添加一个强大的 Blame？
94610发布于 2018-09-19 - 来自专栏iOS开发大全
软件开发入门教程网之Git 查看提交历史
git blame <file> - 以列表形式查看指定文件的历史修改记录。 rewritten636db2c t3301: add tests to use --format="%N"更多 git log 命令可查看：http://git-scm.com/docs/git-loggit blame {#git-blame}如果要查看指定文件的修改记录可以使用 git blame 命令，格式如下：git blame <file>git blame 命令是以列表形式显示修改记录，如下实例：$ git blame README ^d2097aa (tianqixin 2020-08-25 14:59:25 +0800 1) # Runoob Git 测试db9315b0 (kxdang 2020
54020编辑于 2023-01-11 - 来自专栏iOS打包，上架知识大全
开心档-开发入门网之Git查看提交历史
git blame <file> - 以列表形式查看指定文件的历史修改记录。 rewritten 636db2c t3301: add tests to use --format="%N" 更多 git log 命令可查看：Git - git-log Documentation git blame {#git-blame} 如果要查看指定文件的修改记录可以使用 git blame 命令，格式如下： git blame <file> git blame 命令是以列表形式显示修改记录，如下实例： $ git blame README ^d2097aa (tianqixin 2020-08-25 14:59:25 +0800 1) # Runoob Git 测试 db9315b0 (kxdang
60420编辑于 2023-03-21 - 来自专栏vscode从0到高手
VS Code GitLens 十大神技：彻底改变你在 VS Code 中的 Git 工作流
行内 Blame 注解 每行代码末尾自动显示：谁、何时、在哪次提交修改了这行。 通过行内 blame，我立刻知道这是上周五由后端同事为修复一个紧急漏洞加入的。 提示：可通过设置关闭或调整位置，避免干扰。 2. 边栏 Blame 比行内更简洁：在代码左侧边栏（gutter）显示作者和简略 commit 信息。 状态栏 Blame 点击任意一行，VS Code 底部状态栏立即显示该行的完整 Git 信息： ✅ 特点： 零干扰 实时更新 支持快捷键跳转到 commit ️ 6. 安装与配置 在 VS Code 扩展商店搜索 GitLens 安装后重启编辑器 首次使用会提示授权（仅用于私有仓库集成，公共仓库无需） 推荐设置（settings.json）： { "gitlens.blame.format
2.1K10编辑于 2026-02-27 - 来自专栏山河已无恙
关于 Git 重写提交历史的一些笔记
rebase -i HEAD~3 pick f7f3f6d changed my name a bit pick 310154e updated README formatting and added blame pick f7f3f6d changed my name a bit pick 310154e updated README formatting and added blame pick a5f4a0d 想要将它拆分为两次提交：第一个“updated README formatting”，第二个 “added blame” 来代替原来的“updated README formatting and added blame”。 README $ git commit -m 'updated README formatting' $ git add lib/simplegit.rb $ git commit -m 'added blame
71320编辑于 2023-01-30 - 来自专栏软件测试那些事
终于把个人覆盖率统计搞清楚了，还一鱼两吃
大致的方案是这样的， 1）通过Git Blame可以拿到每个代码文件的每一行的行号、内容、最后修改者、commit等数据 2）通过Jacoco获取到(增量）代码覆盖率报告 3）缝合两者的数据，通过行号关联 人 + 覆盖的数据 4）根据人聚合出每个开发人员应该负责 代码行数和被覆盖的代码行数 5）计算出谁的行覆盖率没达标 6）分支覆盖也类似套路 实现 以git blame为例，使用jgit这个库， 下载代码 repo，checkout到指定分支 过滤代码库目录，得到需要blame的文件清单，例如指定 src/main/java下的以.java后缀的文件 对每个文件执行 git blame,得到每个文件的 blame结果。 性能方面，内部测试了一下，以一个1万个文件的代码库为例，git blame了1500个文件，并分析了jacoco.xml中涉及到的500个java文件，总耗时在30秒以内（10个并发）。
61020编辑于 2023-09-07 - 来自专栏MasiMaro 的技术博文
gitsigns
toggle_linel：高亮变更的行 toggle_delete: 显示被删除的行，以红色背景高亮显示 toggle_word_diff: 在两行分别显示修改前和修改后的内容 toggle_current_line_blame 所以我自己的经验告诉我在这个buffer里面最好是只打开 signs、numl、linel、current_line_blame的功能，其他的都关掉。 interval = 1000, follow_files = true }, attach_to_untracked = true, current_line_blame = false, -- Toggle with `:Gitsigns toggle_current_line_blame` current_line_blame_opts = { noremap = true}) vim.api.nvim_set_keymap('n', '<leader>tb', '<cmd>Gitsigns toggle_current_line_blame
1.3K20编辑于 2023-03-08 - 来自专栏运维前线
7.6 Git 工具 - 重写历史
pretty=format:"%h %s" HEAD~3..HEAD a5f4a0d added cat-file 310154e updated README formatting and added blame pick a5f4a0d added cat-file 改为这样： pick 310154e updated README formatting and added blame pick f7f3f6d 想要将它拆分为两次提交：第一个 “updated README formatting”，第二个 “added blame” 来代替原来的 “updated README formatting and added blame”。 README $ git commit -m 'updated README formatting' $ git add lib/simplegit.rb $ git commit -m 'added blame
89360发布于 2019-05-26 - 来自专栏linux百科小宇宙
让Git 多种颜色和自定义log格式输出
parent的短hashes %an 作者名字 %aN mailmap中对应的作者名字 (.mailmap对应，详情参照git-shortlog(1)或者git-blame (1)) %ae 作者邮箱 %aE 作者邮箱 (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1)) % 日期, ISO 8601 格式 %cn 提交者名字 %cN 提交者名字 (.mailmap对应，详情参照git-shortlog(1)或者git-blame (1)) %ce 提交者 email %cE 提交者 email (.mailmap对应，详情参照git-shortlog(1)或者git-blame(1
1.1K30发布于 2021-06-08 - 来自专栏進无尽的文章
基础篇-Welcome to Xcode
把光标移动到出错的那一行， 单击右键选择然后在菜单里选择Show Blame for Line，啊哦，是你干的么？ Xcode8 不能显示blame，show blame for line 灰色不可点解决办法 辅助菜单 它非常有用，它包含了Callers和Callees这样强大的功能，展示代码在什么地方以及被谁调用过
1.7K10发布于 2018-09-12 - 来自专栏运维前线
7.10 Git 工具 - 使用 Git 调试
所以，如果你在代码中看到一个有问题的方法，你可以使用 git blame 标注这个文件，查看这个方法每一行的最后修改时间以及是被谁修改的。 这个例子使用 -L 选项来限制输出范围在第12至22行： $ git blame -L 12,22 simplegit.rb ^4832fe2 (Scott Chacon 2008-03-15 10: (path) 42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21) command("git blame #{path}") 42cf2861 如果你在 git blame 后面加上一个 -C，Git 会分析你正在标注的文件，并且尝试找出文件中从别的地方复制过来的代码片段的原始出处。 对 GITPackUpload.m 执行带 -C 参数的blame命令，你就可以看到代码块的原始出处： $ git blame -C -L 141,153 GITPackUpload.m f344f58d
60330发布于 2019-05-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号