tg-tag: never try to delete one's HEAD
commit7de215b2d93b77feb68361e7d4aa214f7b301853
authorKyle J. McKay <mackyle@gmail.com>
Thu, 8 Mar 2018 19:19:04 +0000 (8 11:19 -0800)
committerKyle J. McKay <mackyle@gmail.com>
Thu, 8 Mar 2018 19:19:04 +0000 (8 11:19 -0800)
tree1e42fbd48c2a63ad36e77f56062b40765195b83b
parentf701b9e10c5e11e7df3cb5a799c485333e61631c
tg-tag: never try to delete one's HEAD

When using `git update-ref -d` without the `--no-deref` option it
helpfully dereferences a symbolic ref first and then operates on
that.  Occassionally that's surprising, but at least the repository
does not end up corrupted.

However, whether HEAD is detached or not, the actual HEAD ref must
never be deleted or the repository itself will become invalid.

Unfortunately Git provides minimal protection against obliterating
your HEAD and will essentially corrupt the repository when its HEAD
is removed (either detached via `git update-ref -d HEAD` or via
`git update-ref --no-deref -d HEAD` for a symbolic HEAD ref).

Prevent loss of one's HEAD by explicity checking for a request to
remove one's HEAD and deny it even if HEAD is symbolic.

Be careful to match HEAD case insensitively too as on a case
insensitive file system deleting "Head" might otherwise still succeed
in removing one's HEAD.

However, do include some advice if HEAD is symbolic about deleting
the ref it points to instead.  Since --delete is a lossy operation,
this requirement to be explicit about what's being deleted provides
an extra measure of protection against accidents.

In addition, always supply the `--no-deref` option so there
are no surprises (such as would likely occur with something like
`git update-ref -d refs/remotes/origin/HEAD` that failed to
provide the `--no-deref` option).

And since we're adding advice, hint that perhaps `--drop` was
intended if `--delete` or `--clear` are used with an explicit
`@{n}` suffix.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
README
tg-tag.sh