Julien Cretel venit, vidit, dixit 17.02.2015 00:40: > On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Julien Cretel <j.cretel@xxxxxxxxxxxx> writes: >> >>> As of Git 2.3.0, the output of "git log --decorate" is ambiguous as to >>> whether the HEAD is detached or not. >> >> It sounds as if you are reporting some regression, but has any >> version of Git ever done so, or is this just a new feature that >> does not exist yet? > > Apologies; I should have explained myself better. I'm not reporting a > regression; > as far as I can tell, "git log --decorate" has always been ambiguous > in that way. > >> >>> More specifically, consider the following output of "git log --decorate": >>> >>> 4d860e9 (HEAD, master, dev) Remove trailing whitespace >>> >>> Whether the HEAD is attached to master or detached, the output is the same. >>> Could/should "git log --decorate" be modified to provide this information? >>> Perhaps something along the lines of >>> >>> 4d860e9 (HEAD -> master, dev) Remove trailing whitespace >>> >>> or >>> >>> 4d860e9 (HEAD = master, dev) Remove trailing whitespace >>> >> >> I personally do not see a need for such a differenciation. Why does >> one even need to know, and is it worth the cost of computing at the >> runtime? > > I believe the "--decorate" flag to be quite popular. I personally like to run > "git log --decorate --graph --oneline --all" to quickly get an idea of the state > of a repo. In my experience, many users do the same, to the point that they > feel the need to define an alias for this command; see the top answers to > http://stackoverflow.com/q/1057564/2541573. > > My problem with the current output of "git log --decorate" is the asymmetry, > so to speak. If the HEAD is detached but pointing at a commit that isn't any > branch's tip, then the user can be sure the HEAD detached; however, if at > least one branch points to the current commit, there is no way to tell. > > I must admit I haven't given much thought about the cost involved, but I can't > imagine performance would take a big hit. Would it? > >> >> Most of the time when I am on detached HEAD it is either a few >> commits behind a tip, or a few commits ahead of a tip. "git branch" will tell you your branches and which one is checked out (or HEAD); "git status" will tell you the latter. "git log" is about the DAG which has absolutely nothing to do with what you have currently checked out. Your expectation may come from the fact that the default argument to "git log" is HEAD; or from what "gitk" and other ui tools do. On the other hand, our decorations can be considered "wrong" in the following sense: if HEAD is a symref it really points to a (branch) ref, not a commit. In this situation, "HEAD" should be the decoration of the branch ref, not of the commit which the branch ref resolves to. But that would apply to annotated tags, as well: they point to tag objects (and should decorate them by the logic above) rather than commit objects. So, what "log --decorate" really and consistently does is resolving ("peeling") any decorating reference until it points to a commit object, and decorate that. A --decorate-detailed mode which does without the peeling could be elucidating - that would need markers for (branch) refs and tag objects in addition to commit objects, though (and an extension of the machinery). Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html