When the squash occurs, a new commit is created that contains all of the changed files. That said, it can happen sooner, especially if you force Git to expire the reflog sooner. This typically happens after 90 days, when the reflog expires. A dangling commit will eventually be garbage collected by Git and removed. They are dangling commits, meaning they have become unreachable unless you know the commit’s hash. The reason that the original commits normally seem to disappear is because they are no longer referenced by any branch. The original commits are no longer part of any branch, but they continue to exist. The original commits are separated from the main branch, and the tag continues to point to the original commit. The tag, however, continues to reference A3. The branch that was squashed now contains a new history, with A3' represents the squashed versions of A1, A2, and A3. When those commits are squashed, a parallel history is created. So what happens if I have a branch with a tag and it gets squashed? As an example, assume there is a main branch with three commits. This alters the branch.įor example, a branch with three commits:īecomes a branch with a single commit after the squash.Īt the end of the operation, the original commits B, C, and D are combined into a single commit, D'. If you’re not familiar with the concept, a squash rewrites the history by combining one or more commits into a single commit. If part of that history is tagged, is the tag lost? Does it get updated to reflect the new history? To understand what happens and why, we need to explore what really happens when you squash your commits. When a commit is squashed, it normally loses the history. What happens if you have tagged a commit and the branch containing it is later squashed? I recently had an interesting question presented to me:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |