On Thu, Oct 11, 2018 at 09:35:28PM +0100, Rafael Ascensão wrote: > 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. Correct. ;) I like your general idea, but I agree with Daniel that it introduces an inconsistency in the interface. > 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. Right, I like that part. It's just that putting "HEAD" there already has a meaning: it would find refs/heads/HEAD. Now I'll grant that's a bad name for a branch (and the source of other confusions, and I think perhaps even something a few commands actively discourage these days). > 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. I don't think this is about resolving HEAD, or showing it. It's about the fact that arguments to "branch" are currently always branch-names, not full refs. -Peff
