Comment by fragmede
2 days ago
This works if the branch exists or creates it if it doesn't exist, but not if it's checked out.
git branch -f branch_name commit
if it's checked out:
git reset --hard commit
2 days ago
This works if the branch exists or creates it if it doesn't exist, but not if it's checked out.
git branch -f branch_name commit
if it's checked out:
git reset --hard commit
> but not if it's checked out
...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency).
You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.
To me that looks like git is leaking implementation details left and right.
So much for "a branch is simply a pointer to a commit"...
Do you react the same way when an OS prevents you from writing to a file with an exclusive lock placed on it? So much for "a file is simply a collection of data stored as a single object"...
If a git repo was purely a collection of meaningless pointers and graph nodes, git would be a graph manipulation utility, not a version control system. The fact that some of those pointers have a meaning is what makes it useful and it doesn't contradict the fact that what you're working on is still just a bunch of pointers and nodes.
Couldn't head just detach without any consistency issue?
Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why?
"error: ref in use by higher layers" makes much more sense to me in this case.
4 replies →