On Thu, Oct 11, 2018 at 06:36:02PM +0200, Daniels Umanovskis wrote: > I am not a fan because it would be yet another inconsistency in the Git > command interface. The output of the proposed command is also a bit inconsistent with the usual output given by git branch, specifically the space alignment on the left, color and * marker. In addition to not respecting --color, it also ignores --verbose and --format. At this stage it's closer to what I would expect from $git rev-parse --abbrev-ref HEAD; than something coming out of $git branch; Resolving HEAD makes it consistent with rest. On Thu, Oct 11, 2018 at 01:51:36PM -0400, Jeff King wrote: > Yeah, I agree. Not sure which parts you meant, so I'll assume you didn't agree with me. I doesn't seem far fetched to ask for an overview of my current branch, feature1, feature2 and all hotfixes with something like: $ git branch --verbose --list HEAD feature1 feature2 hotfix-*; The 'what's my current branch' could be just a particular case of this form. My defense to treat HEAD specially comes in the form that from the user perspective, HEAD is already being resolved to a commit when HEAD is detached (Showing the detached at <hash> message.) Is there a strong reason to *not* "resolve" HEAD when it is attached? Would it be that bad to have some DWIM behaviour here? After all, as HEAD is an invalid name for a branch, nothing would ever match it anyways. Thanks for the input. :) -- Cheers Rafael Ascensão
