Kenneth Cochran <kenneth.cochran101@xxxxxxxxx> writes: > From c1bad54b29ae1c1d8548d248f6ecaa5959e55f7b Mon Sep 17 00:00:00 2001 > From: Kenneth Cochran <kenneth.cochran101@xxxxxxxxx> > Date: Mon, 4 Mar 2019 09:40:22 -0600 > Subject: [RFC PATCH 0/4] Add alias option to git branch > Cc: Sahil Dua <sahildua2305@xxxxxxxxx>, > Duy Nguyen <pclouds@xxxxxxxxx>, > Jeff King <peff@xxxxxxxx> Avoid using these in-body headers. Reader's MUA won't show this "Subject:", but instead show the same "Add alias option to gir branch", among hundreds of mailing list messages, making it very tempting to ignore these four messages. > I find myself often using git symbolic-ref to get around work requirements to use branch names that are not very human friendly. > There are a few problems with this: > - There’s a lot of text to type > - Mistyping certain parts (heads/refs) will do things other than create a branch alias > - It will happily overwrite an existing branch > - Deleting one that is checked out will put HEAD in an invalid state. Meh. All of the above are problems _you_ create by trying to use symbolic refs. If the project wants to use an overlong branch name, using it with "git branch" or "git checkout" or whatever would be a much better solution. Command-line completion will complete long branch names, and "git branch overly-long-name-of-an-existing-branch" will not overwrite an existing branch (without --force). "git branch -d overly-long-name-of-an-existing-branch" would not delete an checked-out branch, either.