{"thread":{"id":"38576","subject":"Should \"git log --decorate\" indicate whether the HEAD is detached?","startedAt":"2015-02-16T22:42:27Z","lastAt":"2015-03-23T10:36:43Z","messageCount":23,"participants":["Julien Cretel","Junio C Hamano","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256173","messageId":"CACdBeKmNazMtzK4hdd7WXMPDr7HdPe+EFpyd3M-TPBAUEY+HpA@mail.gmail.com","threadId":"38576","inReplyTo":null,"subject":"Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Julien Cretel","fromEmail":"j.cretel@umail.ucc.ie","sentAt":"2015-02-16T22:42:27Z","receivedAt":"2015-02-16T22:42:27Z","isPatch":false,"sender":{"key":"j.cretel@umail.ucc.ie","avatar":null},"body":"As of Git 2.3.0, the output of \"git log --decorate\" is ambiguous as to\nwhether the HEAD is detached or not.\nMore specifically, consider the following output of \"git log --decorate\":\n\n    4d860e9 (HEAD, master, dev) Remove trailing whitespace\n\nWhether the HEAD is attached to master or detached, the output is the same.\nCould/should \"git log --decorate\" be modified to provide this information?\nPerhaps something along the lines of\n\n    4d860e9 (HEAD -> master, dev) Remove trailing whitespace\n\nor\n\n    4d860e9 (HEAD = master, dev) Remove trailing whitespace\n\nin case HEAD is attached to master, and the current output if it is\ndetached? Any thoughts?\n(For information, I asked a related question on Stack Overflow a few\nmonths ago: http://stackoverflow.com/q/25392580/2541573.)\n\nAlso, if such a feature is desirable, would its implementation be a\nsuitable \"microproject\" for a prospective GSoC-2015 applicant?\n\nJubobs\n"},{"id":"256174","messageId":"xmqqa90d4fdp.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"CACdBeKmNazMtzK4hdd7WXMPDr7HdPe+EFpyd3M-TPBAUEY+HpA@mail.gmail.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-16T23:15:46Z","receivedAt":"2015-02-16T23:15:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julien Cretel <j.cretel@umail.ucc.ie> writes:\n\n> As of Git 2.3.0, the output of \"git log --decorate\" is ambiguous as to\n> whether the HEAD is detached or not.\n\nIt sounds as if you are reporting some regression, but has any\nversion of Git ever done so, or is this just a new feature that\ndoes not exist yet?\n\n> More specifically, consider the following output of \"git log --decorate\":\n>\n>     4d860e9 (HEAD, master, dev) Remove trailing whitespace\n>\n> Whether the HEAD is attached to master or detached, the output is the same.\n> Could/should \"git log --decorate\" be modified to provide this information?\n> Perhaps something along the lines of\n>\n>     4d860e9 (HEAD -> master, dev) Remove trailing whitespace\n>\n> or\n>\n>     4d860e9 (HEAD = master, dev) Remove trailing whitespace\n>\n\nI personally do not see a need for such a differenciation.  Why does\none even need to know, and is it worth the cost of computing at the\nruntime?\n\nMost of the time when I am on detached HEAD it is either a few\ncommits behind a tip, or a few commits ahead of a tip.\n"},{"id":"256177","messageId":"CACdBeKnWJvUmFaHNrzcX7LtovOLu3PFaeTyoUAUeC7wmYUboDg@mail.gmail.com","threadId":"38576","inReplyTo":"xmqqa90d4fdp.fsf@gitster.dls.corp.google.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Julien Cretel","fromEmail":"j.cretel@umail.ucc.ie","sentAt":"2015-02-16T23:40:27Z","receivedAt":"2015-02-16T23:40:27Z","isPatch":false,"sender":{"key":"j.cretel@umail.ucc.ie","avatar":null},"body":"On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Julien Cretel <j.cretel@umail.ucc.ie> writes:\n>\n>> As of Git 2.3.0, the output of \"git log --decorate\" is ambiguous as to\n>> whether the HEAD is detached or not.\n>\n> It sounds as if you are reporting some regression, but has any\n> version of Git ever done so, or is this just a new feature that\n> does not exist yet?\n\nApologies; I should have explained myself better. I'm not reporting a\nregression;\nas far as I can tell, \"git log --decorate\" has always been ambiguous\nin that way.\n\n>\n>> More specifically, consider the following output of \"git log --decorate\":\n>>\n>>     4d860e9 (HEAD, master, dev) Remove trailing whitespace\n>>\n>> Whether the HEAD is attached to master or detached, the output is the same.\n>> Could/should \"git log --decorate\" be modified to provide this information?\n>> Perhaps something along the lines of\n>>\n>>     4d860e9 (HEAD -> master, dev) Remove trailing whitespace\n>>\n>> or\n>>\n>>     4d860e9 (HEAD = master, dev) Remove trailing whitespace\n>>\n>\n> I personally do not see a need for such a differenciation.  Why does\n> one even need to know, and is it worth the cost of computing at the\n> runtime?\n\nI believe the \"--decorate\" flag to be quite popular. I personally like to run\n\"git log --decorate --graph --oneline --all\" to quickly get an idea of the state\nof a repo. In my experience, many users do the same, to the point that they\nfeel the need to define an alias for this command; see the top answers to\nhttp://stackoverflow.com/q/1057564/2541573.\n\nMy problem with the current output of \"git log --decorate\" is the asymmetry,\nso to speak. If the HEAD is detached but pointing at a commit that isn't any\nbranch's tip, then the user can be sure the HEAD detached; however, if at\nleast one branch points to the current commit, there is no way to tell.\n\nI must admit I haven't given much thought about the cost involved, but I can't\nimagine performance would take a big hit. Would it?\n\n>\n> Most of the time when I am on detached HEAD it is either a few\n> commits behind a tip, or a few commits ahead of a tip.\n"},{"id":"256264","messageId":"54E46635.4060009@drmicha.warpmail.net","threadId":"38576","inReplyTo":"CACdBeKnWJvUmFaHNrzcX7LtovOLu3PFaeTyoUAUeC7wmYUboDg@mail.gmail.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-18T10:15:17Z","receivedAt":"2015-02-18T10:15:17Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Julien Cretel venit, vidit, dixit 17.02.2015 00:40:\n> On Mon, Feb 16, 2015 at 11:15 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Julien Cretel <j.cretel@umail.ucc.ie> writes:\n>>\n>>> As of Git 2.3.0, the output of \"git log --decorate\" is ambiguous as to\n>>> whether the HEAD is detached or not.\n>>\n>> It sounds as if you are reporting some regression, but has any\n>> version of Git ever done so, or is this just a new feature that\n>> does not exist yet?\n> \n> Apologies; I should have explained myself better. I'm not reporting a\n> regression;\n> as far as I can tell, \"git log --decorate\" has always been ambiguous\n> in that way.\n> \n>>\n>>> More specifically, consider the following output of \"git log --decorate\":\n>>>\n>>>     4d860e9 (HEAD, master, dev) Remove trailing whitespace\n>>>\n>>> Whether the HEAD is attached to master or detached, the output is the same.\n>>> Could/should \"git log --decorate\" be modified to provide this information?\n>>> Perhaps something along the lines of\n>>>\n>>>     4d860e9 (HEAD -> master, dev) Remove trailing whitespace\n>>>\n>>> or\n>>>\n>>>     4d860e9 (HEAD = master, dev) Remove trailing whitespace\n>>>\n>>\n>> I personally do not see a need for such a differenciation.  Why does\n>> one even need to know, and is it worth the cost of computing at the\n>> runtime?\n> \n> I believe the \"--decorate\" flag to be quite popular. I personally like to run\n> \"git log --decorate --graph --oneline --all\" to quickly get an idea of the state\n> of a repo. In my experience, many users do the same, to the point that they\n> feel the need to define an alias for this command; see the top answers to\n> http://stackoverflow.com/q/1057564/2541573.\n> \n> My problem with the current output of \"git log --decorate\" is the asymmetry,\n> so to speak. If the HEAD is detached but pointing at a commit that isn't any\n> branch's tip, then the user can be sure the HEAD detached; however, if at\n> least one branch points to the current commit, there is no way to tell.\n> \n> I must admit I haven't given much thought about the cost involved, but I can't\n> imagine performance would take a big hit. Would it?\n> \n>>\n>> Most of the time when I am on detached HEAD it is either a few\n>> commits behind a tip, or a few commits ahead of a tip.\n\n\"git branch\" will tell you your branches and which one is checked out\n(or HEAD); \"git status\" will tell you the latter.\n\n\"git log\" is about the DAG which has absolutely nothing to do with what\nyou have currently checked out.\n\nYour expectation may come from the fact that the default argument to\n\"git log\" is HEAD; or from what \"gitk\" and other ui tools do.\n\nOn the other hand, our decorations can be considered \"wrong\" in the\nfollowing sense: if HEAD is a symref it really points to a (branch) ref,\nnot a commit. In this situation, \"HEAD\" should be the decoration of the\nbranch ref, not of the commit which the branch ref resolves to.\n\nBut that would apply to annotated tags, as well: they point to tag\nobjects (and should decorate them by the logic above) rather than commit\nobjects.\n\nSo, what \"log --decorate\" really and consistently does is resolving\n(\"peeling\") any decorating reference until it points to a commit object,\nand decorate that.\n\nA --decorate-detailed mode which does without the peeling could be\nelucidating - that would need markers for (branch) refs and tag objects\nin addition to commit objects, though (and an extension of the machinery).\n\nMichael\n"},{"id":"256266","messageId":"2df73f987d69531622681a560ce8ccbd88b15501.1424264942.git.git@drmicha.warpmail.net","threadId":"38576","inReplyTo":"54E46635.4060009@drmicha.warpmail.net","subject":"[RFC/PATCH] log: decorate detached HEAD differently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-18T13:19:25Z","receivedAt":"2015-02-18T13:19:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"\"git status\" and \"git branch\" let the user know when the HEAD is\ndetached, while \"git log --decorate\" does not.\n\nChange the decoration by a detached HEAD to \"detached HEAD\". This can be\nseen as giving more information about the decoration item itself in the\nsame way as we prefix tags by \"tag: \".\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nThis turned out to be easy to do, though I am still undecided.\nPersonally, I like to think of refs as objects (and have implemented refname\nobjects in the past), but that view is not too popular.\n\nSo, maybe the analogy between ref peeling and symref resolving (for HEAD) is\nnot that strong after all. They are both indirections, though different technically.\n\nThe RFC patch only checks HEAD for being a symref, the output is analogous to \nthe summary of \"git commit\".\n\n log-tree.c | 8 +++++++-\n 1 file changed, 7 insertions(+), 1 deletion(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 7f0890e..2eac4b6 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -118,8 +118,14 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n \t\ttype = DECORATION_REF_TAG;\n \telse if (!strcmp(refname, \"refs/stash\"))\n \t\ttype = DECORATION_REF_STASH;\n-\telse if (!strcmp(refname, \"HEAD\"))\n+\telse if (!strcmp(refname, \"HEAD\")) {\n+\t\tchar *junk_sha1[20];\n+\t\tchar *head;\n \t\ttype = DECORATION_REF_HEAD;\n+\t\thead = resolve_ref_unsafe(\"HEAD\", 0, junk_sha1, NULL);\n+\t\tif (!strcmp(head, \"HEAD\"))\n+\t\t\trefname = \"detached HEAD\";\n+\t}\n \n \tif (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)\n \t\trefname = prettify_refname(refname);\n-- \n2.3.0.136.g92a3b58\n"},{"id":"256281","messageId":"xmqq8ufv408l.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"54E46635.4060009@drmicha.warpmail.net","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-18T17:07:22Z","receivedAt":"2015-02-18T17:07:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> \"git branch\" will tell you your branches and which one is checked out\n> (or HEAD); \"git status\" will tell you the latter.\n>\n> \"git log\" is about the DAG which has absolutely nothing to do with what\n> you have currently checked out.\n\nYeah, that summarizes my reaction, too.  More importantly, \"log\" is\nabout showing commits and \"--decorate\" is a way to enrich the\npresentation of commits---it talks about commits in terms of refs;\nthe command and the option is not about describing refs and their\nrelationships.\n\nI do not terribly mind showing the fact that HEAD points at a branch\nwhen --decorate talks about HEAD, partly because we will be showing\nboth HEAD and the branch name _anyway_ in the output.  But I am not\nsure if the extra bit of information is more helpful to the readers\nor being distracting.\n\nJulien's \"HEAD=master, other\" vs \"HEAD, master, other\" may be\nsubdued enough to be undistracting, I would guess.  I do not think\nthe distinction between \"HEAD = master\" and \"HEAD -> master\" would\nbe useful, on the other hand.  We already know that the names listed\nall refer to the same commit, which means that we do not have to say\n\"HEAD is detached\" explicitly as long as we have a way to say \"HEAD\npoints at this branch\".  If HEAD is listed and is not marked to\npoint at another branch that is shown, by definition it is detached,\nno?\n"},{"id":"256309","messageId":"54E4EBC4.6000802@drmicha.warpmail.net","threadId":"38576","inReplyTo":"xmqq8ufv408l.fsf@gitster.dls.corp.google.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-18T19:45:08Z","receivedAt":"2015-02-18T19:45:08Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 18.02.2015 18:07:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> \"git branch\" will tell you your branches and which one is checked out\n>> (or HEAD); \"git status\" will tell you the latter.\n>>\n>> \"git log\" is about the DAG which has absolutely nothing to do with what\n>> you have currently checked out.\n> \n> Yeah, that summarizes my reaction, too.  More importantly, \"log\" is\n> about showing commits and \"--decorate\" is a way to enrich the\n> presentation of commits---it talks about commits in terms of refs;\n> the command and the option is not about describing refs and their\n> relationships.\n> \n> I do not terribly mind showing the fact that HEAD points at a branch\n> when --decorate talks about HEAD, partly because we will be showing\n> both HEAD and the branch name _anyway_ in the output.  But I am not\n> sure if the extra bit of information is more helpful to the readers\n> or being distracting.\n> \n> Julien's \"HEAD=master, other\" vs \"HEAD, master, other\" may be\n> subdued enough to be undistracting, I would guess.  I do not think\n> the distinction between \"HEAD = master\" and \"HEAD -> master\" would\n> be useful, on the other hand.  We already know that the names listed\n> all refer to the same commit, which means that we do not have to say\n> \"HEAD is detached\" explicitly as long as we have a way to say \"HEAD\n> points at this branch\".  If HEAD is listed and is not marked to\n> point at another branch that is shown, by definition it is detached,\n> no?\n> \n\nYep, it very well is. Also, that approach would tell you which branch is\nchecked out, though I don't consider that git log's business.\n\nOTOH, it's \"backwards\" in the sense that it marks the \"ordinary\" case\n(HEAD is symref, branch is checked out) specially compared to the\n\"exceptional/dangerous\" case (HEAD is ref, detached). And status, branch\nwill point out that latter case more verbously, too.\n\nMichael\n"},{"id":"256310","messageId":"xmqq8ufv2e62.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"54E4EBC4.6000802@drmicha.warpmail.net","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-18T19:49:25Z","receivedAt":"2015-02-18T19:49:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Yep, it very well is. Also, that approach would tell you which branch is\n> checked out, though I don't consider that git log's business.\n>\n> OTOH, it's \"backwards\" in the sense that it marks the \"ordinary\" case\n> (HEAD is symref, branch is checked out) specially compared to the\n> \"exceptional/dangerous\" case (HEAD is ref, detached).\n\nBoth are ordinary and there is nothing exceptional or dangerous\nabout your HEAD temporarily being detached during a \"rebase -i\"\nsession, for example.\n\n> And status, branch\n> will point out that latter case more verbously, too.\n\nYeah, but as you said, that is not \"log\"'s business.\n"},{"id":"256337","messageId":"54E5B267.9090604@drmicha.warpmail.net","threadId":"38576","inReplyTo":"xmqq8ufv2e62.fsf@gitster.dls.corp.google.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-19T09:52:39Z","receivedAt":"2015-02-19T09:52:39Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 18.02.2015 20:49:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> Yep, it very well is. Also, that approach would tell you which branch is\n>> checked out, though I don't consider that git log's business.\n>>\n>> OTOH, it's \"backwards\" in the sense that it marks the \"ordinary\" case\n>> (HEAD is symref, branch is checked out) specially compared to the\n>> \"exceptional/dangerous\" case (HEAD is ref, detached).\n> \n> Both are ordinary and there is nothing exceptional or dangerous\n> about your HEAD temporarily being detached during a \"rebase -i\"\n> session, for example.\n\nSure, that's why I put it in quotes. That's only how it is perceived by\nsome users, and I suppose it's that kind of users that we are trying to\nhelp here.\n\n>> And status, branch\n>> will point out that latter case more verbously, too.\n> \n> Yeah, but as you said, that is not \"log\"'s business.\n\nI still think decorations \"detached HEAD\" resp. \"HEAD\" for the two cases\nare more natural, if we want to include any additional information at\nall. Just think of:\n\ndeadbeef (HEAD=master, topicbranch, tag: v1)\n\nlog/rev-list is about commit objects. All the refs above resolve to the\nsame commit, so why are only two of them equal?\n\nIn fact, they are very unequal, since HEAD would be \"ref:\nrefs/heads/master\" whereas master would \"deadbeef\". They are equal in\nthe other (detached) case! I'm not telling you any news here, I just\nwant to point out how badly misleading that notation is.\n\nSo, I would suggest to \"decorate the decorations\", by saying something\nlike \"detached HEAD\", and maybe some version of \"HEAD at master\" (I'd\nprefer just \"HEAD\") and possibly more info on the tags (\"s-tag\" or\n\"signed tag\" etc).\n\nMichael\n"},{"id":"256342","messageId":"CACdBeKnqZuu50knWs=aCm7295no880EN9TYY+hMnfSdVvdZ4AA@mail.gmail.com","threadId":"38576","inReplyTo":"xmqq8ufv408l.fsf@gitster.dls.corp.google.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Julien Cretel","fromEmail":"j.cretel@umail.ucc.ie","sentAt":"2015-02-19T11:13:42Z","receivedAt":"2015-02-19T11:13:42Z","isPatch":false,"sender":{"key":"j.cretel@umail.ucc.ie","avatar":null},"body":"On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> Julien's \"HEAD=master, other\" vs \"HEAD, master, other\" may be\n> subdued enough to be undistracting, I would guess.  I do not think\n> the distinction between \"HEAD = master\" and \"HEAD -> master\" would\n> be useful, on the other hand.\n\nJust to clarify, I suggested these two notations as alternatives for\ndenoting the same state: \"HEAD is attached to master\". They were not\nmeant to denote different states. Accordingly, a detached HEAD could\nbe denoted by \"HEAD, master, other\" (i.e. the same as the current\noutput of \"git log --decorate\").\n"},{"id":"256390","messageId":"CAPc5daWz-Xa7q6f9RzgTP4has8DcCG4QgK7SMGNbH6KGnEyr2Q@mail.gmail.com","threadId":"38576","inReplyTo":"CACdBeKnqZuu50knWs=aCm7295no880EN9TYY+hMnfSdVvdZ4AA@mail.gmail.com","subject":"Re: Should \"git log --decorate\" indicate whether the HEAD is detached?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-20T08:13:48Z","receivedAt":"2015-02-20T08:13:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Thu, Feb 19, 2015 at 3:13 AM, Julien Cretel <j.cretel@umail.ucc.ie> wrote:\n> On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> Julien's \"HEAD=master, other\" vs \"HEAD, master, other\" may be\n>> subdued enough to be undistracting, I would guess.  I do not think\n>> the distinction between \"HEAD = master\" and \"HEAD -> master\" would\n>> be useful, on the other hand.\n>\n> Just to clarify, I suggested these two notations as alternatives for\n> denoting the same state: \"HEAD is attached to master\". They were not\n> meant to denote different states. Accordingly, a detached HEAD could\n> be denoted by \"HEAD, master, other\" (i.e. the same as the current\n> output of \"git log --decorate\").\n\nThat makes it even better than my misunderstood version ;-)  A list\nthat is usually \"A, B, C\" that sometimes has \"A, B=C\" is inconspicuous\nenough not to be distracting too much, I would say.\n\nThanks.\n"},{"id":"257171","messageId":"015d6992d2c2165045117f763d9ce3131979c2db.1425658434.git.git@drmicha.warpmail.net","threadId":"38576","inReplyTo":"CAPc5daWz-Xa7q6f9RzgTP4has8DcCG4QgK7SMGNbH6KGnEyr2Q@mail.gmail.com","subject":"[PATCH] log: decorate detached HEAD differently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-06T16:15:16Z","receivedAt":"2015-03-06T16:15:16Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"\"git status\" and \"git branch\" let the user know when the HEAD is\ndetached, as well as the current branch, while \"git log --decorate\" does not.\n\nChange the decoration by a non-detached HEAD pointing to branch foo to\n\"HEAD->foo\". This can be seen as giving more information about the\ndecoration item itself in the same way as we prefix tags by \"tag: \".\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n\nNotes:\n    v2 decorates the HEAD pointing to master as \"HEAD->master\", a detached\n    HEAD just as \"HEAD\". The \"->\" hopefully conveys the symlink nature - a\n    \"=\" would be confusing.\n    \n    Somehow I still prefer \"detached HEAD\", dunno. Maybe in addition?\n    \n    Note that now a checked branch is listed twice, once as target of the\n    HEAD, once as branch: They are two different refs and colored differently.\n\n log-tree.c                             | 8 +++++++-\n t/t4013/diff.log_--decorate=full_--all | 2 +-\n t/t4013/diff.log_--decorate_--all      | 2 +-\n t/t4207-log-decoration-colors.sh       | 2 +-\n 4 files changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 7f0890e..38862bb 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -118,8 +118,11 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n \t\ttype = DECORATION_REF_TAG;\n \telse if (!strcmp(refname, \"refs/stash\"))\n \t\ttype = DECORATION_REF_STASH;\n-\telse if (!strcmp(refname, \"HEAD\"))\n+\telse if (!strcmp(refname, \"HEAD\")) {\n+\t\tunsigned char junk_sha1[20];\n \t\ttype = DECORATION_REF_HEAD;\n+\t\trefname = resolve_ref_unsafe(\"HEAD\", 0, junk_sha1, NULL);\n+\t}\n \n \tif (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)\n \t\trefname = prettify_refname(refname);\n@@ -198,6 +201,9 @@ void format_decorations_extended(struct strbuf *sb,\n \t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n \t\tif (decoration->type == DECORATION_REF_TAG)\n \t\t\tstrbuf_addstr(sb, \"tag: \");\n+\t\telse if (decoration->type == DECORATION_REF_HEAD &&\n+\t\t\t strcmp(decoration->name, \"HEAD\"))\n+\t\t\tstrbuf_addstr(sb, \"HEAD->\");\n \t\tstrbuf_addstr(sb, decoration->name);\n \t\tstrbuf_addstr(sb, color_reset);\n \t\tprefix = separator;\ndiff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all\nindex 44d4525..3758ae9 100644\n--- a/t/t4013/diff.log_--decorate=full_--all\n+++ b/t/t4013/diff.log_--decorate=full_--all\n@@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n \n     Rearranged lines in dir/sub\n \n-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)\n+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->refs/heads/master, refs/heads/master)\n Merge: 9a6d494 c7a2ab9\n Author: A U Thor <author@example.com>\n Date:   Mon Jun 26 00:04:00 2006 +0000\ndiff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all\nindex 27d3eab..df702ae 100644\n--- a/t/t4013/diff.log_--decorate_--all\n+++ b/t/t4013/diff.log_--decorate_--all\n@@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n \n     Rearranged lines in dir/sub\n \n-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)\n+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->master, master)\n Merge: 9a6d494 c7a2ab9\n Author: A U Thor <author@example.com>\n Date:   Mon Jun 26 00:04:00 2006 +0000\ndiff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\nindex 925f577..0437ff2 100755\n--- a/t/t4207-log-decoration-colors.sh\n+++ b/t/t4207-log-decoration-colors.sh\n@@ -44,7 +44,7 @@ test_expect_success setup '\n '\n \n cat >expected <<EOF\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD${c_reset}${c_commit},\\\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD->master${c_reset}${c_commit},\\\n  ${c_tag}tag: v1.0${c_reset}${c_commit},\\\n  ${c_tag}tag: B${c_reset}${c_commit},\\\n  ${c_branch}master${c_reset}${c_commit})${c_reset} B\n-- \n2.3.1.303.g5174db1\n"},{"id":"257172","messageId":"54F9D3D2.2070300@drmicha.warpmail.net","threadId":"38576","inReplyTo":"015d6992d2c2165045117f763d9ce3131979c2db.1425658434.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] log: decorate detached HEAD differently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-06T16:20:34Z","receivedAt":"2015-03-06T16:20:34Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 06.03.2015 17:15:\n... and maybe the patch title should be different for v2, too:\n\nlog: decorate non-detached HEAD differently\n\nNot my day today it seems, but this is my last patch for today.\n\nMichael\n"},{"id":"257188","messageId":"xmqq61aeymlv.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"015d6992d2c2165045117f763d9ce3131979c2db.1425658434.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] log: decorate detached HEAD differently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-06T19:03:40Z","receivedAt":"2015-03-06T19:03:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> \"git status\" and \"git branch\" let the user know when the HEAD is\n> detached, as well as the current branch, while \"git log --decorate\" does not.\n>\n> Change the decoration by a non-detached HEAD pointing to branch foo to\n> \"HEAD->foo\". This can be seen as giving more information about the\n> decoration item itself in the same way as we prefix tags by \"tag: \".\n>\n> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n> ---\n>\n> Notes:\n>     v2 decorates the HEAD pointing to master as \"HEAD->master\", a detached\n>     HEAD just as \"HEAD\". The \"->\" hopefully conveys the symlink nature - a\n>     \"=\" would be confusing.\n>     \n>     Somehow I still prefer \"detached HEAD\", dunno. Maybe in addition?\n>     \n>     Note that now a checked branch is listed twice, once as target of the\n>     HEAD, once as branch: They are two different refs and colored differently.\n\nThe pointee of HEAD would always be branch and will always appear on\nthe output when you show HEAD->$name_of_that_branch; is it feasible\nto drop the duplicate, I wonder?\n\n>\n>  log-tree.c                             | 8 +++++++-\n>  t/t4013/diff.log_--decorate=full_--all | 2 +-\n>  t/t4013/diff.log_--decorate_--all      | 2 +-\n>  t/t4207-log-decoration-colors.sh       | 2 +-\n>  4 files changed, 10 insertions(+), 4 deletions(-)\n>\n> diff --git a/log-tree.c b/log-tree.c\n> index 7f0890e..38862bb 100644\n> --- a/log-tree.c\n> +++ b/log-tree.c\n> @@ -118,8 +118,11 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n>  \t\ttype = DECORATION_REF_TAG;\n>  \telse if (!strcmp(refname, \"refs/stash\"))\n>  \t\ttype = DECORATION_REF_STASH;\n> -\telse if (!strcmp(refname, \"HEAD\"))\n> +\telse if (!strcmp(refname, \"HEAD\")) {\n> +\t\tunsigned char junk_sha1[20];\n>  \t\ttype = DECORATION_REF_HEAD;\n> +\t\trefname = resolve_ref_unsafe(\"HEAD\", 0, junk_sha1, NULL);\n> +\t}\n>  \n>  \tif (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)\n>  \t\trefname = prettify_refname(refname);\n> @@ -198,6 +201,9 @@ void format_decorations_extended(struct strbuf *sb,\n>  \t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n>  \t\tif (decoration->type == DECORATION_REF_TAG)\n>  \t\t\tstrbuf_addstr(sb, \"tag: \");\n> +\t\telse if (decoration->type == DECORATION_REF_HEAD &&\n> +\t\t\t strcmp(decoration->name, \"HEAD\"))\n> +\t\t\tstrbuf_addstr(sb, \"HEAD->\");\n>  \t\tstrbuf_addstr(sb, decoration->name);\n>  \t\tstrbuf_addstr(sb, color_reset);\n>  \t\tprefix = separator;\n> diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all\n> index 44d4525..3758ae9 100644\n> --- a/t/t4013/diff.log_--decorate=full_--all\n> +++ b/t/t4013/diff.log_--decorate=full_--all\n> @@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n>  \n>      Rearranged lines in dir/sub\n>  \n> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)\n> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->refs/heads/master, refs/heads/master)\n>  Merge: 9a6d494 c7a2ab9\n>  Author: A U Thor <author@example.com>\n>  Date:   Mon Jun 26 00:04:00 2006 +0000\n> diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all\n> index 27d3eab..df702ae 100644\n> --- a/t/t4013/diff.log_--decorate_--all\n> +++ b/t/t4013/diff.log_--decorate_--all\n> @@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n>  \n>      Rearranged lines in dir/sub\n>  \n> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)\n> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->master, master)\n>  Merge: 9a6d494 c7a2ab9\n>  Author: A U Thor <author@example.com>\n>  Date:   Mon Jun 26 00:04:00 2006 +0000\n> diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\n> index 925f577..0437ff2 100755\n> --- a/t/t4207-log-decoration-colors.sh\n> +++ b/t/t4207-log-decoration-colors.sh\n> @@ -44,7 +44,7 @@ test_expect_success setup '\n>  '\n>  \n>  cat >expected <<EOF\n> -${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD${c_reset}${c_commit},\\\n> +${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD->master${c_reset}${c_commit},\\\n>   ${c_tag}tag: v1.0${c_reset}${c_commit},\\\n>   ${c_tag}tag: B${c_reset}${c_commit},\\\n>   ${c_branch}master${c_reset}${c_commit})${c_reset} B\n"},{"id":"257372","messageId":"54FD64D1.6080103@drmicha.warpmail.net","threadId":"38576","inReplyTo":"xmqq61aeymlv.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] log: decorate detached HEAD differently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-09T09:16:01Z","receivedAt":"2015-03-09T09:16:01Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 06.03.2015 20:03:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> \"git status\" and \"git branch\" let the user know when the HEAD is\n>> detached, as well as the current branch, while \"git log --decorate\" does not.\n>>\n>> Change the decoration by a non-detached HEAD pointing to branch foo to\n>> \"HEAD->foo\". This can be seen as giving more information about the\n>> decoration item itself in the same way as we prefix tags by \"tag: \".\n>>\n>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n>> ---\n>>\n>> Notes:\n>>     v2 decorates the HEAD pointing to master as \"HEAD->master\", a detached\n>>     HEAD just as \"HEAD\". The \"->\" hopefully conveys the symlink nature - a\n>>     \"=\" would be confusing.\n>>     \n>>     Somehow I still prefer \"detached HEAD\", dunno. Maybe in addition?\n>>     \n>>     Note that now a checked branch is listed twice, once as target of the\n>>     HEAD, once as branch: They are two different refs and colored differently.\n> \n> The pointee of HEAD would always be branch and will always appear on\n> the output when you show HEAD->$name_of_that_branch; is it feasible\n> to drop the duplicate, I wonder?\n\nIt's doable but not nice, because we cannot take the order in which refs\nare processed for granted.\n\nI also think that we shouldn't simply check whether branch foo is\nchecked out (when decorating with foo) - we need to know whether HEAD is\namong the refs which are eligible for decoration. That caveat is also\ntrue for the \"always\" above. (I don't think we allow decorating by a\nsubset of all refs right now, but it would be useful, and easy given the\nfor-each-ref machinery.)\n\nAlso, HEAD and foo are two different refs, so even if HEAD has the value\n\"foo\", I think we should really show them both anyways.\n\nAlternatively, we could decorate by (HEAD, *foo, master, tag: release)\nif foo is checked out, just like branch does.\n\n\n>>  log-tree.c                             | 8 +++++++-\n>>  t/t4013/diff.log_--decorate=full_--all | 2 +-\n>>  t/t4013/diff.log_--decorate_--all      | 2 +-\n>>  t/t4207-log-decoration-colors.sh       | 2 +-\n>>  4 files changed, 10 insertions(+), 4 deletions(-)\n>>\n>> diff --git a/log-tree.c b/log-tree.c\n>> index 7f0890e..38862bb 100644\n>> --- a/log-tree.c\n>> +++ b/log-tree.c\n>> @@ -118,8 +118,11 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in\n>>  \t\ttype = DECORATION_REF_TAG;\n>>  \telse if (!strcmp(refname, \"refs/stash\"))\n>>  \t\ttype = DECORATION_REF_STASH;\n>> -\telse if (!strcmp(refname, \"HEAD\"))\n>> +\telse if (!strcmp(refname, \"HEAD\")) {\n>> +\t\tunsigned char junk_sha1[20];\n>>  \t\ttype = DECORATION_REF_HEAD;\n>> +\t\trefname = resolve_ref_unsafe(\"HEAD\", 0, junk_sha1, NULL);\n>> +\t}\n>>  \n>>  \tif (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)\n>>  \t\trefname = prettify_refname(refname);\n>> @@ -198,6 +201,9 @@ void format_decorations_extended(struct strbuf *sb,\n>>  \t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n>>  \t\tif (decoration->type == DECORATION_REF_TAG)\n>>  \t\t\tstrbuf_addstr(sb, \"tag: \");\n>> +\t\telse if (decoration->type == DECORATION_REF_HEAD &&\n>> +\t\t\t strcmp(decoration->name, \"HEAD\"))\n>> +\t\t\tstrbuf_addstr(sb, \"HEAD->\");\n>>  \t\tstrbuf_addstr(sb, decoration->name);\n>>  \t\tstrbuf_addstr(sb, color_reset);\n>>  \t\tprefix = separator;\n>> diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all\n>> index 44d4525..3758ae9 100644\n>> --- a/t/t4013/diff.log_--decorate=full_--all\n>> +++ b/t/t4013/diff.log_--decorate=full_--all\n>> @@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n>>  \n>>      Rearranged lines in dir/sub\n>>  \n>> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)\n>> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->refs/heads/master, refs/heads/master)\n>>  Merge: 9a6d494 c7a2ab9\n>>  Author: A U Thor <author@example.com>\n>>  Date:   Mon Jun 26 00:04:00 2006 +0000\n>> diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all\n>> index 27d3eab..df702ae 100644\n>> --- a/t/t4013/diff.log_--decorate_--all\n>> +++ b/t/t4013/diff.log_--decorate_--all\n>> @@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n>>  \n>>      Rearranged lines in dir/sub\n>>  \n>> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)\n>> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD->master, master)\n>>  Merge: 9a6d494 c7a2ab9\n>>  Author: A U Thor <author@example.com>\n>>  Date:   Mon Jun 26 00:04:00 2006 +0000\n>> diff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\n>> index 925f577..0437ff2 100755\n>> --- a/t/t4207-log-decoration-colors.sh\n>> +++ b/t/t4207-log-decoration-colors.sh\n>> @@ -44,7 +44,7 @@ test_expect_success setup '\n>>  '\n>>  \n>>  cat >expected <<EOF\n>> -${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD${c_reset}${c_commit},\\\n>> +${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD->master${c_reset}${c_commit},\\\n>>   ${c_tag}tag: v1.0${c_reset}${c_commit},\\\n>>   ${c_tag}tag: B${c_reset}${c_commit},\\\n>>   ${c_branch}master${c_reset}${c_commit})${c_reset} B\n"},{"id":"257439","messageId":"xmqqh9tt623d.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"54FD64D1.6080103@drmicha.warpmail.net","subject":"Re: [PATCH] log: decorate detached HEAD differently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T02:03:18Z","receivedAt":"2015-03-10T02:03:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Junio C Hamano venit, vidit, dixit 06.03.2015 20:03:\n>> Michael J Gruber <git@drmicha.warpmail.net> writes:\n>>>     \n>>>     Note that now a checked branch is listed twice, once as target of the\n>>>     HEAD, once as branch: They are two different refs and colored differently.\n>> \n>> The pointee of HEAD would always be branch and will always appear on\n>> the output when you show HEAD->$name_of_that_branch; is it feasible\n>> to drop the duplicate, I wonder?\n>\n> It's doable but not nice, because we cannot take the order in which refs\n> are processed for granted.\n\nThat is true, but when we format them into a single line in the\nheader in response to --decorate (or %d), don't we have all of them\nalready at hand---does the order still matter?\n\nHere is an illustration of what I had in mind, made on a random\ncommit I happened to have checked out that does not have your\npatches on this topic.  Half of the change is a new helper function,\nand the other half is mostly reindenting.\n\n log-tree.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-------\n 1 file changed, 63 insertions(+), 8 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 7f0890e..e0c5865 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -173,6 +173,43 @@ static void show_children(struct rev_info *opt, struct commit *commit, int abbre\n }\n \n /*\n+ * Do we have HEAD in the output, and also the branch it points at?\n+ * If so, find that decoration entry for that current branch.\n+ */\n+static const struct name_decoration *current_pointed_by_HEAD(const struct name_decoration *decoration)\n+{\n+\tconst struct name_decoration *list, *head = NULL;\n+\tconst char *branch_name = NULL;\n+\tunsigned char unused[20];\n+\tint rru_flags;\n+\n+\t/* First find HEAD */\n+\tfor (list = decoration; list; list = list->next)\n+\t\tif (list->type == DECORATION_REF_HEAD) {\n+\t\t\thead = list;\n+\t\t\tbreak;\n+\t\t}\n+\tif (!head)\n+\t\treturn NULL;\n+\n+\t/* Now resolve and find the matching current branch */\n+\tbranch_name = resolve_ref_unsafe(\"HEAD\", 0, unused, &rru_flags);\n+\tif (!(rru_flags & REF_ISSYMREF))\n+\t\treturn NULL;\n+\tif (!skip_prefix(branch_name, \"refs/heads/\", &branch_name))\n+\t\treturn NULL;\n+\n+\t/* OK, do we have that ref in the list? */\n+\tfor (list = decoration; list; list = list->next)\n+\t\tif ((list->type == DECORATION_REF_LOCAL) &&\n+\t\t    !strcmp(branch_name, list->name)) {\n+\t\t\treturn list;\n+\t\t}\n+\n+\treturn NULL;\n+}\n+\n+/*\n  * The caller makes sure there is no funny color before calling.\n  * format_decorations_extended makes sure the same after return.\n  */\n@@ -184,6 +221,7 @@ void format_decorations_extended(struct strbuf *sb,\n \t\t\tconst char *suffix)\n {\n \tconst struct name_decoration *decoration;\n+\tconst struct name_decoration *current_and_HEAD;\n \tconst char *color_commit =\n \t\tdiff_get_color(use_color, DIFF_COMMIT);\n \tconst char *color_reset =\n@@ -192,15 +230,32 @@ void format_decorations_extended(struct strbuf *sb,\n \tdecoration = get_name_decoration(&commit->object);\n \tif (!decoration)\n \t\treturn;\n+\n+\tcurrent_and_HEAD = current_pointed_by_HEAD(decoration);\n \twhile (decoration) {\n-\t\tstrbuf_addstr(sb, color_commit);\n-\t\tstrbuf_addstr(sb, prefix);\n-\t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n-\t\tif (decoration->type == DECORATION_REF_TAG)\n-\t\t\tstrbuf_addstr(sb, \"tag: \");\n-\t\tstrbuf_addstr(sb, decoration->name);\n-\t\tstrbuf_addstr(sb, color_reset);\n-\t\tprefix = separator;\n+\t\t/*\n+\t\t * When both current and HEAD are there, only\n+\t\t * show HEAD->current where HEAD would have\n+\t\t * appeaed, skipping the entry for current.\n+\t\t */\n+\t\tif (current_and_HEAD && decoration == current_and_HEAD)\n+\t\t\t;\n+\t\telse {\n+\t\t\tstrbuf_addstr(sb, color_commit);\n+\t\t\tstrbuf_addstr(sb, prefix);\n+\t\t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n+\t\t\tif (decoration->type == DECORATION_REF_TAG)\n+\t\t\t\tstrbuf_addstr(sb, \"tag: \");\n+\n+\t\t\tif (current_and_HEAD &&\n+\t\t\t    decoration->type == DECORATION_REF_HEAD)\n+\t\t\t\tstrbuf_addf(sb, \"HEAD->%s\", current_and_HEAD->name);\n+\t\t\telse\n+\t\t\t\tstrbuf_addstr(sb, decoration->name);\n+\t\t\tstrbuf_addstr(sb, color_reset);\n+\n+\t\t\tprefix = separator;\n+\t\t}\n \t\tdecoration = decoration->next;\n \t}\n \tstrbuf_addstr(sb, color_commit);\n"},{"id":"257458","messageId":"54FEC8D0.2060304@drmicha.warpmail.net","threadId":"38576","inReplyTo":"xmqqh9tt623d.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] log: decorate detached HEAD differently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-10T10:34:56Z","receivedAt":"2015-03-10T10:34:56Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 10.03.2015 03:03:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> Junio C Hamano venit, vidit, dixit 06.03.2015 20:03:\n>>> Michael J Gruber <git@drmicha.warpmail.net> writes:\n>>>>     \n>>>>     Note that now a checked branch is listed twice, once as target of the\n>>>>     HEAD, once as branch: They are two different refs and colored differently.\n>>>\n>>> The pointee of HEAD would always be branch and will always appear on\n>>> the output when you show HEAD->$name_of_that_branch; is it feasible\n>>> to drop the duplicate, I wonder?\n>>\n>> It's doable but not nice, because we cannot take the order in which refs\n>> are processed for granted.\n> \n> That is true, but when we format them into a single line in the\n> header in response to --decorate (or %d), don't we have all of them\n> already at hand---does the order still matter?\n> \n> Here is an illustration of what I had in mind, made on a random\n> commit I happened to have checked out that does not have your\n> patches on this topic.  Half of the change is a new helper function,\n> and the other half is mostly reindenting.\n\nYes, the patch illustrates pretty well what I meant by \"doable but not\nnice\" :)\n\nBut I also said:\n\n> Also, HEAD and foo are two different refs, so even if HEAD has the value\n> \"foo\", I think we should really show them both anyways.\n> \n> Alternatively, we could decorate by (HEAD, *foo, master, tag: release)\n> if foo is checked out, just like branch does.\n\nI guess I will have to apply your patch and feel what it's like in\npractical use in order to change my mind...\n\nMichael\n"},{"id":"257471","messageId":"cover.1425995310.git.git@drmicha.warpmail.net","threadId":"38576","inReplyTo":"54FEC8D0.2060304@drmicha.warpmail.net","subject":"[PATCHv2 0/2] log decorations for HEAD","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-10T13:53:19Z","receivedAt":"2015-03-10T13:53:19Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"So it didn't take too long to convince me after all :)\n\nHere comes Junio's version, preceded by a cleanup of the color\nsetting and resetting for decorations.\n\nJunio C Hamano (1):\n  log: decorate HEAD with branch name\n\nMichael J Gruber (1):\n  log-tree: properly reset colors\n\n log-tree.c                        | 76 ++++++++++++++++++++++++++++++++++-----\n t/t4013/diff.log_--decorate_--all |  2 +-\n t/t4207-log-decoration-colors.sh  | 16 ++++-----\n 3 files changed, 77 insertions(+), 17 deletions(-)\n\n-- \n2.3.2.346.gb6960c9\n"},{"id":"257469","messageId":"0b167704d88ed6b7e8f950f0a05dd51b2b9c6406.1425995310.git.git@drmicha.warpmail.net","threadId":"38576","inReplyTo":"54FEC8D0.2060304@drmicha.warpmail.net","subject":"[PATCHv2 1/2] log-tree: properly reset colors","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-10T13:53:20Z","receivedAt":"2015-03-10T13:53:20Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Except for the separator, all output items reset the color immediately.\nDo the same for the separator.\n\nThis affects only cases where setting color A does not override color B,\nsuch as when one is forground and one background.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n log-tree.c                       |  1 +\n t/t4207-log-decoration-colors.sh | 16 ++++++++--------\n 2 files changed, 9 insertions(+), 8 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 7f0890e..53bb526 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -195,6 +195,7 @@ void format_decorations_extended(struct strbuf *sb,\n \twhile (decoration) {\n \t\tstrbuf_addstr(sb, color_commit);\n \t\tstrbuf_addstr(sb, prefix);\n+\t\tstrbuf_addstr(sb, color_reset);\n \t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n \t\tif (decoration->type == DECORATION_REF_TAG)\n \t\t\tstrbuf_addstr(sb, \"tag: \");\ndiff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\nindex 925f577..6b8ad4f 100755\n--- a/t/t4207-log-decoration-colors.sh\n+++ b/t/t4207-log-decoration-colors.sh\n@@ -44,15 +44,15 @@ test_expect_success setup '\n '\n \n cat >expected <<EOF\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_HEAD}HEAD${c_reset}${c_commit},\\\n- ${c_tag}tag: v1.0${c_reset}${c_commit},\\\n- ${c_tag}tag: B${c_reset}${c_commit},\\\n- ${c_branch}master${c_reset}${c_commit})${c_reset} B\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_tag}tag: A1${c_reset}${c_commit},\\\n- ${c_remoteBranch}other/master${c_reset}${c_commit})${c_reset} A1\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_stash}refs/stash${c_reset}${c_commit})${c_reset}\\\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}${c_commit},\\\n+ ${c_reset}${c_tag}tag: v1.0${c_reset}${c_commit},\\\n+ ${c_reset}${c_tag}tag: B${c_reset}${c_commit},\\\n+ ${c_reset}${c_branch}master${c_reset}${c_commit})${c_reset} B\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_tag}tag: A1${c_reset}${c_commit},\\\n+ ${c_reset}${c_remoteBranch}other/master${c_reset}${c_commit})${c_reset} A1\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_stash}refs/stash${c_reset}${c_commit})${c_reset}\\\n  On master: Changes to A.t\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_tag}tag: A${c_reset}${c_commit})${c_reset} A\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_tag}tag: A${c_reset}${c_commit})${c_reset} A\n EOF\n \n # We want log to show all, but the second parent to refs/stash is irrelevant\n-- \n2.3.2.346.gb6960c9\n"},{"id":"257470","messageId":"b6960c9364da471a674fb24b8dd35ebdb8269243.1425995310.git.git@drmicha.warpmail.net","threadId":"38576","inReplyTo":"54FEC8D0.2060304@drmicha.warpmail.net","subject":"[PATCHv2 2/2] log: decorate HEAD with branch name","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-10T13:53:21Z","receivedAt":"2015-03-10T13:53:21Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"From: Junio C Hamano <gitster@pobox.com>\n\nCurrently, log decorations do not indicate which branch is checked out\nand whether HEAD is detached.\n\nWhen branch foo is checked out, change the \"HEAD, foo\" part of the\ndecorations to \"HEAD -> foo\". This serves to indicate both ref\ndecorations (helped by the spacing) as well as their relationshsip.\nAs a consequence, \"HEAD\" without any \" -> \" denotes a detached HEAD now.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n\nNotes:\n    The patch is really Junio's now.\n    I just simplified the if's and added colors and tests.\n    The spaces around \"->\" should help to make the branch stick out even\n    without colors.\n\n log-tree.c                        | 77 ++++++++++++++++++++++++++++++++++-----\n t/t4013/diff.log_--decorate_--all |  2 +-\n t/t4207-log-decoration-colors.sh  |  6 +--\n 3 files changed, 72 insertions(+), 13 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 53bb526..2c1ed0f 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -173,6 +173,43 @@ static void show_children(struct rev_info *opt, struct commit *commit, int abbre\n }\n \n /*\n+ * Do we have HEAD in the output, and also the branch it points at?\n+ * If so, find that decoration entry for that current branch.\n+ */\n+static const struct name_decoration *current_pointed_by_HEAD(const struct name_decoration *decoration)\n+{\n+\tconst struct name_decoration *list, *head = NULL;\n+\tconst char *branch_name = NULL;\n+\tunsigned char unused[20];\n+\tint rru_flags;\n+\n+\t/* First find HEAD */\n+\tfor (list = decoration; list; list = list->next)\n+\t\tif (list->type == DECORATION_REF_HEAD) {\n+\t\t\thead = list;\n+\t\t\tbreak;\n+\t\t}\n+\tif (!head)\n+\t\treturn NULL;\n+\n+\t/* Now resolve and find the matching current branch */\n+\tbranch_name = resolve_ref_unsafe(\"HEAD\", 0, unused, &rru_flags);\n+\tif (!(rru_flags & REF_ISSYMREF))\n+\t\treturn NULL;\n+\tif (!skip_prefix(branch_name, \"refs/heads/\", &branch_name))\n+\t\treturn NULL;\n+\n+\t/* OK, do we have that ref in the list? */\n+\tfor (list = decoration; list; list = list->next)\n+\t\tif ((list->type == DECORATION_REF_LOCAL) &&\n+\t\t    !strcmp(branch_name, list->name)) {\n+\t\t\treturn list;\n+\t\t}\n+\n+\treturn NULL;\n+}\n+\n+/*\n  * The caller makes sure there is no funny color before calling.\n  * format_decorations_extended makes sure the same after return.\n  */\n@@ -184,6 +221,7 @@ void format_decorations_extended(struct strbuf *sb,\n \t\t\tconst char *suffix)\n {\n \tconst struct name_decoration *decoration;\n+\tconst struct name_decoration *current_and_HEAD;\n \tconst char *color_commit =\n \t\tdiff_get_color(use_color, DIFF_COMMIT);\n \tconst char *color_reset =\n@@ -192,16 +230,37 @@ void format_decorations_extended(struct strbuf *sb,\n \tdecoration = get_name_decoration(&commit->object);\n \tif (!decoration)\n \t\treturn;\n+\n+\tcurrent_and_HEAD = current_pointed_by_HEAD(decoration);\n \twhile (decoration) {\n-\t\tstrbuf_addstr(sb, color_commit);\n-\t\tstrbuf_addstr(sb, prefix);\n-\t\tstrbuf_addstr(sb, color_reset);\n-\t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n-\t\tif (decoration->type == DECORATION_REF_TAG)\n-\t\t\tstrbuf_addstr(sb, \"tag: \");\n-\t\tstrbuf_addstr(sb, decoration->name);\n-\t\tstrbuf_addstr(sb, color_reset);\n-\t\tprefix = separator;\n+\t\t/*\n+\t\t * When both current and HEAD are there, only\n+\t\t * show HEAD->current where HEAD would have\n+\t\t * appeared, skipping the entry for current.\n+\t\t */\n+\t\tif (decoration != current_and_HEAD) {\n+\t\t\tstrbuf_addstr(sb, color_commit);\n+\t\t\tstrbuf_addstr(sb, prefix);\n+\t\t\tstrbuf_addstr(sb, color_reset);\n+\t\t\tstrbuf_addstr(sb, decorate_get_color(use_color, decoration->type));\n+\t\t\tif (decoration->type == DECORATION_REF_TAG)\n+\t\t\t\tstrbuf_addstr(sb, \"tag: \");\n+\n+\t\t\tstrbuf_addstr(sb, decoration->name);\n+\n+\t\t\tif (current_and_HEAD &&\n+\t\t\t    decoration->type == DECORATION_REF_HEAD) {\n+\t\t\t\tstrbuf_addstr(sb, color_reset);\n+\t\t\t\tstrbuf_addstr(sb, color_commit);\n+\t\t\t\tstrbuf_addstr(sb, \" -> \");\n+\t\t\t\tstrbuf_addstr(sb, color_reset);\n+\t\t\t\tstrbuf_addstr(sb, decorate_get_color(use_color, current_and_HEAD->type));\n+\t\t\t\tstrbuf_addstr(sb, current_and_HEAD->name);\n+\t\t\t}\n+\t\t\tstrbuf_addstr(sb, color_reset);\n+\n+\t\t\tprefix = separator;\n+\t\t}\n \t\tdecoration = decoration->next;\n \t}\n \tstrbuf_addstr(sb, color_commit);\ndiff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all\nindex 27d3eab..3aa16a9 100644\n--- a/t/t4013/diff.log_--decorate_--all\n+++ b/t/t4013/diff.log_--decorate_--all\n@@ -5,7 +5,7 @@ Date:   Mon Jun 26 00:06:00 2006 +0000\n \n     Rearranged lines in dir/sub\n \n-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)\n+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD -> master)\n Merge: 9a6d494 c7a2ab9\n Author: A U Thor <author@example.com>\n Date:   Mon Jun 26 00:04:00 2006 +0000\ndiff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\nindex 6b8ad4f..f8008b6 100755\n--- a/t/t4207-log-decoration-colors.sh\n+++ b/t/t4207-log-decoration-colors.sh\n@@ -44,10 +44,10 @@ test_expect_success setup '\n '\n \n cat >expected <<EOF\n-${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}${c_commit},\\\n+${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_HEAD}HEAD${c_reset}${c_commit} ->\\\n+ ${c_reset}${c_branch}master${c_reset}${c_commit},\\\n  ${c_reset}${c_tag}tag: v1.0${c_reset}${c_commit},\\\n- ${c_reset}${c_tag}tag: B${c_reset}${c_commit},\\\n- ${c_reset}${c_branch}master${c_reset}${c_commit})${c_reset} B\n+ ${c_reset}${c_tag}tag: B${c_reset}${c_commit})${c_reset} B\n ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_tag}tag: A1${c_reset}${c_commit},\\\n  ${c_reset}${c_remoteBranch}other/master${c_reset}${c_commit})${c_reset} A1\n ${c_commit}COMMIT_ID${c_reset}${c_commit} (${c_reset}${c_stash}refs/stash${c_reset}${c_commit})${c_reset}\\\n-- \n2.3.2.346.gb6960c9\n"},{"id":"257477","messageId":"xmqqr3sw234j.fsf@gitster.dls.corp.google.com","threadId":"38576","inReplyTo":"cover.1425995310.git.git@drmicha.warpmail.net","subject":"Re: [PATCHv2 0/2] log decorations for HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T17:06:52Z","receivedAt":"2015-03-10T17:06:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> So it didn't take too long to convince me after all :)\n>\n> Here comes Junio's version, preceded by a cleanup of the color\n> setting and resetting for decorations.\n>\n> Junio C Hamano (1):\n>   log: decorate HEAD with branch name\n>\n> Michael J Gruber (1):\n>   log-tree: properly reset colors\n>\n>  log-tree.c                        | 76 ++++++++++++++++++++++++++++++++++-----\n>  t/t4013/diff.log_--decorate_--all |  2 +-\n>  t/t4207-log-decoration-colors.sh  | 16 ++++-----\n>  3 files changed, 77 insertions(+), 17 deletions(-)\n\nHmph, is the \"do not leak commit color\" one the same as 5ee87585\n(log --decorate: do not leak \"commit\" color into the next item,\n2015-03-04) aka $gmane/264788 [*1*] or is there something I missed?\n\n\n[References]\n\n*1* http://thread.gmane.org/gmane.comp.version-control.git/264063/focus=264788\n"},{"id":"257547","messageId":"54FFF69E.3090104@drmicha.warpmail.net","threadId":"38576","inReplyTo":"xmqqr3sw234j.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCHv2 0/2] log decorations for HEAD","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-03-11T08:02:38Z","receivedAt":"2015-03-11T08:02:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 10.03.2015 18:06:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> So it didn't take too long to convince me after all :)\n>>\n>> Here comes Junio's version, preceded by a cleanup of the color\n>> setting and resetting for decorations.\n>>\n>> Junio C Hamano (1):\n>>   log: decorate HEAD with branch name\n>>\n>> Michael J Gruber (1):\n>>   log-tree: properly reset colors\n>>\n>>  log-tree.c                        | 76 ++++++++++++++++++++++++++++++++++-----\n>>  t/t4013/diff.log_--decorate_--all |  2 +-\n>>  t/t4207-log-decoration-colors.sh  | 16 ++++-----\n>>  3 files changed, 77 insertions(+), 17 deletions(-)\n> \n> Hmph, is the \"do not leak commit color\" one the same as 5ee87585\n> (log --decorate: do not leak \"commit\" color into the next item,\n> 2015-03-04) aka $gmane/264788 [*1*] or is there something I missed?\n> \n\nUh, I missed that one. The commit msg confuses me somewhat (color.diff\nvs color.decorate), but the patch to log-tree.c is the same, and so I\nassume the patch to t4207 is the same, too. 2/2 from here should go on\ntop of 7/7 from there, accordingly.\n\n> [References]\n> \n> *1* http://thread.gmane.org/gmane.comp.version-control.git/264063/focus=264788\n> \n> \n> \n> \n"},{"id":"258357","messageId":"CACdBeKkpH8O+tXbB9dK0GDBZc3gPMTf-WDt_FOk9mjZT2ranMQ@mail.gmail.com","threadId":"38576","inReplyTo":"cover.1425995310.git.git@drmicha.warpmail.net","subject":"Re: [PATCHv2 0/2] log decorations for HEAD","fromName":"Julien Cretel","fromEmail":"j.cretel@umail.ucc.ie","sentAt":"2015-03-23T10:36:43Z","receivedAt":"2015-03-23T10:36:43Z","isPatch":false,"sender":{"key":"j.cretel@umail.ucc.ie","avatar":null},"body":"On Tue, Mar 10, 2015 at 1:53 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n>\n> So it didn't take too long to convince me after all :)\n>\n> Here comes Junio's version, preceded by a cleanup of the color\n> setting and resetting for decorations.\n>\n> Junio C Hamano (1):\n>   log: decorate HEAD with branch name\n>\n> Michael J Gruber (1):\n>   log-tree: properly reset colors\n>\n>  log-tree.c                        | 76 ++++++++++++++++++++++++++++++++++-----\n>  t/t4013/diff.log_--decorate_--all |  2 +-\n>  t/t4207-log-decoration-colors.sh  | 16 ++++-----\n>  3 files changed, 77 insertions(+), 17 deletions(-)\n>\n> --\n> 2.3.2.346.gb6960c9\n>\n\nI'm so glad you've implemented this. Thanks again.\n\nI hope I'll get familiar enough with the Git codebase to start posting\npatches of my own, in the future.\n\nJubobs\n"}]}