We can investigate by running git reflog. Most likely Git is storing a reference to our detached commit in the reflog. This is also a good example of how it is hard to fully lose data with Git. This is a prime example of why git prune is not to be used stand-alone outside of git gc. Somewhere Git is still maintaining a reference to it. Why would this happen? Well, the commit is most likely not fully detached. Empty output implies that the prune will not actually delete anything. This command will most likely return empty output. ~/git-prune-demo $ git prune -dry-run -verbose First though, let us return to the main branch using git checkout If we examine the log here we can see that the "added another line to hello.txt" commit is now back in the log output! Now that we know the repository is in a good simulation state with a detached commit we can practice using git prune. When we check out the detached commit, Git is thoughtful enough to give us a detailed message explaining that we are in a detached state. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |