Web lists-archives.com

Re: [RFC PATCH 0/4] Add alias option to git branch




On Tue, Mar 5, 2019 at 7:21 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> 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.
>

Thanks, I'll be sure to fix that in the future.

>
> > 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.
>

I definitely agree, I had only meant that these were problems with my
current solution of using git symbolic-ref directly - problems that these
patches are meant to fix. I probably should have included more
information about why I use that solution in the first place.

Command line completion definitely helps in some cases, but not all - for
example, let's say I have two branches, feature/PRODUCT-13032 and
feature/PRODUCT-13023. These branches are generally short lived, so
they're not around long enough that the numbers have much meaning to
me - even with tab completion, I need to have the bug tracking software
open alongside the terminal in order to keep them separated. This can be
even more pronounced when working on several branches that are
numbered in sequence.

`git checkout foo` is much easier than `git checkout feature/PRODUCT-13032`,
even with tab completion. There's a significant number of stack overflow
questions about this functionality, and for almost all of them,
`git symbolic-ref refs/heads/newname refs/heads/branchname` is the accepted
answer. There's definitely interest in having this ability besides just me.