请教有关一个 git 历史提交的问题

我的配置自从 fork purcell 以后就一直是自己本地维护。半年后嫌弃 git 历史提交太多,导致 magit 有点卡,于是通过这条命令(来自某个SO)删除了除了我之外的其它所有人的提交

git filter-branch --commit-filter '
    if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
    then
            skip_commit "[email protected]";
    else
            git commit-tree "[email protected]";
    fi' HEAD

其中

skip_commit(){
    shift;
    while [ -n "$1" ];
    do
        shift;
        map "$1";
        shift;
    done;
}

现在 git shortlog -sn 结果为 1228 lukertty 然而今天突然发现计算commit次数的命令应该是 git rev-list --all --count,结果为4748

https://stackoverflow.com/questions/677436/how-to-get-the-git-commit-count

请问如何把剩下的 3500条删除掉?(不知道怎么计算的,purcell 本人也只有2700条)

你更改之后,git pull 的时候就有问题了吧?

我后来再也没有pull过 因为变化实在太大了 改到自己的github上了

你不如直接 rm .git, 然后从新 git init, 我感觉使用其他人的配置永远只是过渡,到最后,都需要自己维护自己的配置。

可是毕竟已经维护了这么久 还是有点心疼的

这有什么心疼的,我emacs配置当时有1000多commit,我直接删除了。。

1 个赞

刚试了下 git rebase -i 还是挺好使的,直接把一堆 commit squash 到一起就行。

2 个赞

然后这条命令有达到目的没?

Darl McBribe 应该只是个例子,你实际自己运行的时候应该有改吧?

删除所有除你之外的 Commit,看起来应该用:

git filter-branch --commit-filter '
	if [ "$GIT_AUTHOR_NAME" = "你的名字" ];
	then
		git commit-tree "[email protected]";
	else
		skip_commit "[email protected]";
	fi' HEAD

注意原来是删除某个人的 Commit,你需要的删除掉除了你之外的 Commit,所以上面的 if 的分支有调换。

当然成功了… 之前就是这么做的。所以 git shortlog -sn 的结果只有我一个人了呢。否则会有很多其他人的。

我就是奇怪为什么 git rev-list --all --count 的结果会有这么多。但是在其它项目里的git rev-list --all --count显示结果是正常的。

目测原因是生成了不明的backup。

最终的解决方法简单粗暴:删掉整个.git 文件夹,然后从github上clone 一份下来。 现在的 git rev-list --all --count 结果是正常的。

之前的 .git 文件夹大小11M,现在的大小是 1.2M

一段时间以后,你自己的 commit 数量也到达某个数字,然后又要删除?

正确的姿势难道不是限制一次性显示的 commit 数量?只显示 lastN 条,magit 不支持?

话说有人用 magit 打开过上万条 commit log 的 repo 么?:grin:

我之前有一次就这么干了,为了用 brew 安装某个版本的软件,按网上指引跑去改东西。

3 万多条的 commit,加载新的 log 时就特别卡。不过应付楼主的 3000 条是不会有卡顿感觉的,只能是你配置问题。

好了,有想尝试的胖友们请举手!

Formula [master] % git rev-list --all --count
32542
Formula [master] % pwd
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula

这种“删除”方式带来另一个问题,假设 commit 历史如下:

master --a--b--c--d--e--f-->

删除 c--d--e 之后,产生一个超级 commit F

master --a--b--F-->

F 包含原 c--d--e--f 所有内容。虽然 commit 记录看着很爽,都是你提交的,但是再也分不清那个文件是谁以及为何修改的了,这样的 commit 意义何在?

因为是个人配置,所以我的git的作用其实就是备份, 一般都是updateXXX,所以 commit没什么价值

你说的有道理。。。我的教训也证明了这个命令有危险。。。

commit 还是尽量保存为好,不差那点资源。

小范围用用 rebase 就好。

如果要和他人协作,rebase 等修改 commit 的工具,一定要慎用,不然朋友会诅咒你。。。。

本地 commit 怎么折腾都没事,用来合并小更改挺好用的。

至于协作,我的理解是凡是需要 force push 的东西一般不要用。

magit 几年前就支持限制 commit log 显示数量了 https://github.com/magit/magit/pull/1990, 所以 commit 数量多少根本不是问题。

其实主要还是 git 设计巧妙,天然支持分页。

然而该卡还是要卡的 :frowning: 打开上面提到的 Homebrew repo 试一下就知道了,我就部分因为这个跑回去继续用 tig 了。 当然,这个也不能苛责,估计绝大部分 git GUI 客户端都要卡。