Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.
Suddenly having a detached HEAD isn't as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.
Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.
For folks unaware, the technical git term, here, is a 'ref'. Everything that points to a commit is a ref, whether it's HEAD, the tip of a branch, or a tag. If the git manpage mentions a 'ref' that's what it's talking about.
Right. I just wanted to keep it as simple as possible.
Oh, no worries, just figured I'd add that extra little bit of detail as it's a useful hook into a lot of other git concepts.
Honestly I've come to realise that being precise is the simplest in the long run
People get overloaded with words. You have to focus on one concept at a time. Let them ask for others.
Orphaned commits can get garbage collected at some point, though.
Oh fuck. I didn't think of that. Than you for reminding me.
Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won't allow it.
Oh yeah, and anybody else who had fetched in those commits may still have them as well. It's hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.
Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.
Suddenly having a detached HEAD isn't as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.
Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.
For folks unaware, the technical git term, here, is a 'ref'. Everything that points to a commit is a ref, whether it's HEAD, the tip of a branch, or a tag. If the git manpage mentions a 'ref' that's what it's talking about.
Right. I just wanted to keep it as simple as possible.
Oh, no worries, just figured I'd add that extra little bit of detail as it's a useful hook into a lot of other git concepts.
Honestly I've come to realise that being precise is the simplest in the long run
People get overloaded with words. You have to focus on one concept at a time. Let them ask for others.
Orphaned commits can get garbage collected at some point, though.
Oh fuck. I didn't think of that. Than you for reminding me.
Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won't allow it.
Oh yeah, and anybody else who had fetched in those commits may still have them as well. It's hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.
This I call decapitation