git rebase:重新提交仍在索引中吗? [英] git rebase: rebased commit still in index?

问题描述

当我读到有关 git-rebase 的文章时，我了解到提交应该丢失.我之所以这样说是因为我注意到，了解了基于重新提交的提交后，就可以回想起来了.
假设我有以下三个提交

When I read about git-rebase, I understood the rebased commits should get lost. I say should because I noticed that, knowing the rebased commit sha, I can recall it.
Suppose I have the following three commits

A -> B -> C

其中C的sha是cshaid.然后，如果我用git rebase -i HEAD~2交互式地将fixing-up C变基为B，然后用git log检查结果，则可以得到预期的结果，即

where C's sha is cshaid. Then, if I interactively rebase fixing-up C into B with git rebase -i HEAD~2 and then I check the result with git log, I obtain the expected result, meaning

A -> B'

其中B'的阴影与B的阴影不同.
但是，再次运行git log cshaid会显示

where B''s sha is different from B's sha.
However, running git log cshaid shows again

A -> B -> C

问题:这是已知的行为吗?我尝试阅读git rebase --help，但是找不到相关信息.为什么不简单地忘记基于重新提交的提交?我的意思是，仅当您知道自己在做什么并且可以做到这一点时，执行rebase才是一种危险的操作，这就是拥有肮脏索引(或将这些无用的提交保存在任何地方)的关键所在吗?我想念什么吗?
重现步骤(并更好地理解我的疑问).如果您愿意重现这种情况，请尝试:

Questions: is this a known behavior? I tried reading git rebase --help but couldn't find related info. Why rebased commits are not simply forgot? I mean, rebase is kind of a dangerous operation to be performed only if you know what you are doing and you can do it, which is the point in having a dirty index (or wherever these useless commits are kept)? Am I missing something?
Step to reproduce (and to better understand my doubts). If you are willing to reproduce the situation, try with:

1. mkdir sampledir && cd sampledir && git init
2. touch file && git add -A . && git commit -m "Initial"
3. 编辑文件，然后git commit -am "First modification"
4. 编辑文件，然后git commit -am "Second modification"
5. git log，您将看到三个提交，请记住Second modification
的阴影
6. git rebase -i HEAD~2，将fixup Second modification转换为First modification
7. git log，您将看到两次提交，其中First modification的sha现在与步骤5中的不同
8. 但是，git log sha-for-"Second modification"将在此列表中显示与第5点完全相同的树

1. mkdir sampledir && cd sampledir && git init
2. touch file && git add -A . && git commit -m "Initial"
3. edit file, then git commit -am "First modification"
4. edit file, then git commit -am "Second modification"
5. git log, you will see three commits, remember the sha for Second modification
6. git rebase -i HEAD~2, the fixup Second modification into First modification
7. git log, you will see two commits, where the sha for First modification is now different than in step 5
8. however, git log sha-for-"Second modification" will show the exact same tree as point 5 in this list

推荐答案

是的，这是预期的行为.未引用的提交最终将被垃圾回收，从而从磁盘中清除.它们会保留几天(默认为14天)，但是在14天计时器开始计时之前，对象也必须已从reflog中过期(默认情况下，无法访问的对象会在30天后过期).

Yes, this is the expected behavior. Unreferenced commits will eventually be garbage collected and thereby purged from disk. They're kept around for a number of days (by default 14), but before that 14-day timer even starts ticking the objects must have expired from the reflog as well (unreachable objects by default expire after 30 days).

与StackOverflow相关的问题:

Related StackOverflow questions:

• git reflog过期并且git fsck --unreachable
• 列出和删除Git提交没有分支的(悬空的?)

• git reflog expire and git fsck --unreachable
• Listing and deleting Git commits that are under no branch (dangling?)

这篇关于git rebase:重新提交仍在索引中吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！