{"thread":{"id":"45115","subject":"[RFC PATCH] show decorations at the end of the line","startedAt":"2017-02-11T18:02:38Z","lastAt":"2017-02-21T22:24:57Z","messageCount":20,"participants":["Linus Torvalds","Junio C Hamano","Jeff King","Stephan Beyer","Jacob Keller"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"311343","messageId":"alpine.LFD.2.20.1702110943460.31350@i7.lan","threadId":"45115","inReplyTo":null,"subject":"[RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-11T18:02:30Z","receivedAt":"2017-02-11T18:02:38Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nSo I use \"--show-decorations\" all the time because I find it very useful \nto see where the origin branch is, where tags are etc. In fact, my global \ngit config file has\n\n [log]\n decorate = auto\n\nin it, so that I don't have to type it out all the time when I just do my \nusual 'git log\". It's lovely.\n\nHowever, it does make one particular case uglier: with commit decorations, \nthe \"oneline\" commit format ends up being not very pretty:\n\n [torvalds@i7 git]$ git log --oneline -10\n 3f07dac29 (HEAD -> master) pathspec: don't error out on all-exclusionary pathspec patterns\n ca4a562f2 pathspec magic: add '^' as alias for '!'\n 02555c1b2 ls-remote: add \"--diff\" option to show only refs that differ\n 6e3a7b339 (tag: v2.12.0-rc0, origin/master, origin/HEAD) Git 2.12-rc0\n fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'\n 74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'\n 36acf4123 Merge branch 'rs/object-id'\n ecc486b1f Merge branch 'js/re-running-failed-tests'\n 4ba6bb2d1 Merge branch 'sb/submodule-update-initial-runs-custom-script'\n 5348021c6 Merge branch 'sb/submodule-recursive-absorb'\n\nand note how the decoration comes right after the shortened commit hash, \nbreaking up the alignment of the messages. \n\nThe above doesn't show it with the colorization: I also have\n\n [color]\n ui=auto\n\nso on my terminal the decoration is also nicely colorized which makes it \nmuch more obvious, it's not as obvious in this message.\n\nThe oneline message handling is already pretty special, this makes it even \nmore special by putting the decorations at the end of the line:\n\n 3f07dac29 pathspec: don't error out on all-exclusionary pathspec patterns (HEAD -> master)\n ca4a562f2 pathspec magic: add '^' as alias for '!'\n 02555c1b2 ls-remote: add \"--diff\" option to show only refs that differ\n 6e3a7b339 Git 2.12-rc0 (tag: v2.12.0-rc0, origin/master, origin/HEAD)\n fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'\n 74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'\n 36acf4123 Merge branch 'rs/object-id'\n ecc486b1f Merge branch 'js/re-running-failed-tests'\n 4ba6bb2d1 Merge branch 'sb/submodule-update-initial-runs-custom-script'\n 5348021c6 Merge branch 'sb/submodule-recursive-absorb'\n\nwhich looks a lot better (again, this is all particularly noticeable with \ncolorization).\n\nNOTE! There's a very special case for \"git log --oneline -g\" that shows \nthe reflogs as oneliners, and this does *not* fix that special case. It's \na lot more involved and relies on the exact show_reflog_message() \nimplementation, so I left the format for that alone, along with a comment \nabout how it's not at the end of line.\n\nSigned-off-by: Linus Torvalds \n---\n\nI've signed off on this, because I think it's an \"obvious\" improvement, \nbut I'm putting the \"RFC\" in the subject line because this is clearly a \nsubjective thing.\n\n\"oneline\" really is special: the other commit formats will just put the \ncommit SHA1 at the end of the line anyway. And with manual formats, the \nplacement of decorations is also manual, so this doesn't affect that \ncase.\n\nComments?\n\n log-tree.c | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 8c2415747..3bf88182e 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -622,10 +622,13 @@ void show_log(struct rev_info *opt)\n \t\t\t find_unique_abbrev(parent->object.oid.hash,\n \t\t\t\t\t\t abbrev_commit));\n \t\tfputs(diff_get_color_opt(&opt->diffopt, DIFF_RESET), opt->diffopt.file);\n-\t\tshow_decorations(opt, commit);\n \t\tif (opt->commit_format == CMIT_FMT_ONELINE) {\n+\t\t\t/* Not at end of line, but.. */\n+\t\t\tif (opt->reflog_info)\n+\t\t\t\tshow_decorations(opt, commit);\n \t\t\tputc(' ', opt->diffopt.file);\n \t\t} else {\n+\t\t\tshow_decorations(opt, commit);\n \t\t\tputc('\\n', opt->diffopt.file);\n \t\t\tgraph_show_oneline(opt->graph);\n \t\t}\n@@ -716,6 +719,8 @@ void show_log(struct rev_info *opt)\n \t\topt->missing_newline = 0;\n \n \tgraph_show_commit_msg(opt->graph, opt->diffopt.file, &msgbuf);\n+\tif (ctx.fmt == CMIT_FMT_ONELINE)\n+\t\tshow_decorations(opt, commit);\n \tif (opt->use_terminator && !commit_format_is_empty(opt->commit_format)) {\n \t\tif (!opt->missing_newline)\n \t\t\tgraph_show_padding(opt->graph);\n"},{"id":"311344","messageId":"CA+55aFw2S14a4_4YK0b6PNK4TH_AUo_+2JN+PTyBTufNeB5t6A@mail.gmail.com","threadId":"45115","inReplyTo":"alpine.LFD.2.20.1702110943460.31350@i7.lan","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-11T18:13:44Z","receivedAt":"2017-02-11T18:13:49Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds\n wrote:\n>\n> I've signed off on this, because I think it's an \"obvious\" improvement,\n> but I'm putting the \"RFC\" in the subject line because this is clearly a\n> subjective thing.\n\nSide note: the one downside of showing the decorations at the end of\nthe line is that now they are obviously at the end of the line - and\nthus likely to be more hidden by things like line truncation.\n\nThe default git settings (LESS=FRX) no longer truncate log output\nlines, but if you use \"-S\" or \"--chop-long-lines\", you will obviously\nbe missing the end of long lines.\n\nSo moving the decorations to the end does obviously have a real UI\nimpact, apart from just being \"prettier\".\n\nI just wanted to point that out. I still prefer decorations at ends of\nlines (and yes, that's despite the fact that I actually personally use\nthe traditional git setting of \"LESS=FRSX\"), but it is perhaps\nsomething that people should be aware of if this patch causes\ndiscussion.\n\n Linus\n"},{"id":"311393","messageId":"xmqq1sv2fq6m.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"CA+55aFw2S14a4_4YK0b6PNK4TH_AUo_+2JN+PTyBTufNeB5t6A@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T08:30:41Z","receivedAt":"2017-02-13T08:30:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds\n> wrote:\n>>\n>> I've signed off on this, because I think it's an \"obvious\" improvement,\n>> but I'm putting the \"RFC\" in the subject line because this is clearly a\n>> subjective thing.\n>\n> Side note: the one downside of showing the decorations at the end of\n> the line is that now they are obviously at the end of the line - and\n> thus likely to be more hidden by things like line truncation.\n\nSide note: I refrained from commenting on this patch because\neverybody knows that the what I would say anyway ;-) and I didn't\nwant to speak first to discourage others from raising their opinion.\n\nAn obvious downside is that people (against all recommendations) are\nlikely to have written a loose script expecting the --oneline format\nis cast in stone. I personally think it is OK to break them as long\nas \"workaround\" (aka kosher way to do what they have been doing) is\nobvious and easily doable, and in this case their script can switch\nto use --format to keep using the order of fields and format they\nhave been relying on.\n\nIt would be nice if we can have that --format string they can use\nsomewhere in the log message, so that I can cut & paste it into the\nrelease notes that contains this change (i.e. \"those who want to\nkeep using the traditional --oneline --decorate can use this string\nas pretty.my1line configuration variable and use --pretty=my1line\ninstead\").\n"},{"id":"311423","messageId":"CA+55aFy-vvOBu5Y4KDeteUyK-7U7yTa1HoqHo+hME1=8bq7Xhw@mail.gmail.com","threadId":"45115","inReplyTo":"xmqq1sv2fq6m.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-13T19:33:18Z","receivedAt":"2017-02-13T19:33:25Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Feb 13, 2017 at 12:30 AM, Junio C Hamano wrote:\n>\n> An obvious downside is that people (against all recommendations) are\n> likely to have written a loose script expecting the --oneline format\n> is cast in stone.\n\nActually, I don't believe that is the case wrt decorations.\n\nWhy?\n\nIf you script the --oneline format and parse the output, you won't\nhave any decorations at all unless you are crazy (you can set\n\"log.decorations=true\", but that will truly screw up any scripting).\n\nAnd if you actually want decorations, and you're parsing them, you are\n*not* going to script it with \"--oneline --decorations\", because the\nend result is basically impossible to parse already (because it's\nambiguous - think about parentheses in the commit message).\n\nSo if you actually want decorations for parsing, you'd do something like\n\n git log --pretty=\"%h '%D' %s\"\n\nwhich is at least parseable (because now the decoration separator is\nunconditional.\n\nYeah, I guess you could use \"--decorations --color=always\" and then\nuse the color codes to parse the decorations, but that's so\ncomplicated as to be unrealistic.\n\nAnd I considered adding a format string explanation, something along\nthe lines of\n\n - oneline used to mean \"--pretty=%h%d %s\", now it means \"%h %s%d\" instead\n\nbut that's actually not true. The \"oneline\" format was much more\ncomplex than that, in that it has special rules for \"-g\", and it has\nall those colorization ones too.\n\n Linus\n"},{"id":"311441","messageId":"xmqq7f4tdcua.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"CA+55aFy-vvOBu5Y4KDeteUyK-7U7yTa1HoqHo+hME1=8bq7Xhw@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T21:01:49Z","receivedAt":"2017-02-13T21:02:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And if you actually want decorations, and you're parsing them, you are\n> *not* going to script it with \"--oneline --decorations\", because the\n> end result is basically impossible to parse already (because it's\n> ambiguous - think about parentheses in the commit message).\n\nOK. So let's wait to hear from others if they like the \"obviously\"\nimproved output. Even though I find the decorations indispensable\nin my \"git log\" output, I personally do not have much preference\neither way, as my screen is often wide enough ;-)\n\nThanks. We'd need to update the tests that expects the old style\noutput, though.\n"},{"id":"311462","messageId":"20170213223819.gr3wndswieu4bbvn@sigill.intra.peff.net","threadId":"45115","inReplyTo":"xmqq7f4tdcua.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-13T22:38:19Z","receivedAt":"2017-02-13T22:38:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 13, 2017 at 01:01:49PM -0800, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > And if you actually want decorations, and you're parsing them, you are\n> > *not* going to script it with \"--oneline --decorations\", because the\n> > end result is basically impossible to parse already (because it's\n> > ambiguous - think about parentheses in the commit message).\n> \n> OK. So let's wait to hear from others if they like the \"obviously\"\n> improved output. Even though I find the decorations indispensable\n> in my \"git log\" output, I personally do not have much preference\n> either way, as my screen is often wide enough ;-)\n\nI have a slight preference for the new output (decorations at the end)\nversus the original, but I could go either way.\n\nI don't think the scripting compatibility concerns are an issue, for all\nthe reasons given in the thread.\n\nThere is one related option, --source, which also puts its data between\nthe hash and the subject in --oneline. In theory that should be treated\nsimilarly, though:\n\n 1. It's already really ugly, as it does not even get the parentheses\n and coloring.\n\n 2. It's perhaps more likely to get scripted, as it really is parseable\n in the current state.\n\nI'm not sure if a better path forward would be to just extend the idea\nof \"decorator\" to possibly include more than just ref-tips. On the other\nhand, if you really want to get fancy with formatting, we already have a\ncomplete formatting language. Perhaps it should learn a placeholder for\nthe \"--source\" data.\n\nSimilarly, I've often wanted a \"contained in this tags/branches\"\nannotation for each commit. It's not too expensive to compute if you\ntopo-sort the set of commits and just paint down as you traverse.\n\nAnyway, I think none of that needs to block changes to --decorate\noutput. Just thinking out loud.\n\n-Peff\n"},{"id":"311573","messageId":"8cf9e548-bf6d-7cbc-f538-da2fbf489bc7@gmx.net","threadId":"45115","inReplyTo":"xmqq1sv2fq6m.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2017-02-14T20:36:02Z","receivedAt":"2017-02-14T20:36:34Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn 02/13/2017 09:30 AM, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n>> On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds\n>> wrote:\n>>>\n>>> I've signed off on this, because I think it's an \"obvious\" improvement,\n>>> but I'm putting the \"RFC\" in the subject line because this is clearly a\n>>> subjective thing.\n>>\n>> Side note: the one downside of showing the decorations at the end of\n>> the line is that now they are obviously at the end of the line - and\n>> thus likely to be more hidden by things like line truncation.\n> \n> Side note: I refrained from commenting on this patch because\n> everybody knows that the what I would say anyway ;-) and I didn't\n> want to speak first to discourage others from raising their opinion.\n\nA further side note: the current behavior of\n\n\tgit log --oneline --decorate\n\nis equivalent to\n\n\tgit log --pretty='format:%C(auto)%h%d %s'\n\nand Linus' preferred version is equivalent to\n\n\tgit log --pretty='format:%C(auto)%h %s%d'\n\nMost Git users I know have their own favorite version of git log\n--pretty=format:... sometimes with --graph as an alias (\"git lg\" or \"git\nlogk\" (because its output reminds of gitk) or something).\n\nI don't know what the main benefit of this patch would be, but if it\ngets accepted, it should probably be mentioned somewhere that the old\nbehavior is easily accessible using the line mentioned above.\n\nCheers\nStephan\n"},{"id":"311595","messageId":"xmqqr330779h.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"xmqq7f4tdcua.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-14T22:11:06Z","receivedAt":"2017-02-14T22:11:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Thanks. We'd need to update the tests that expects the old style\n> output, though.\n\nThe updates to the expectation look like this (already squashed).\nThe --source decorations in 4202 are also shown at the end, which\nprobably is in line with the way --show-decorations adds them at the\nend of the line, but was somewhat surprising from reading only the\nlog message.\n\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 48b55bfd27..dea2d449ab 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -1353,9 +1353,9 @@ test_expect_success 'set up --source tests' '\n \n test_expect_success 'log --source paints branch names' '\n \tcat >expect <<-\\EOF &&\n-\t09e12a9\tsource-b three\n-\t8e393e1\tsource-a two\n-\t1ac6c77\tsource-b one\n+\t09e12a9 three\tsource-b\n+\t8e393e1 two\tsource-a\n+\t1ac6c77 one\tsource-b\n \tEOF\n \tgit log --oneline --source source-a source-b >actual &&\n \ttest_cmp expect actual\n@@ -1364,9 +1364,9 @@ test_expect_success 'log --source paints branch names' '\n test_expect_success 'log --source paints tag names' '\n \tgit tag -m tagged source-tag &&\n \tcat >expect <<-\\EOF &&\n-\t09e12a9\tsource-tag three\n-\t8e393e1\tsource-a two\n-\t1ac6c77\tsource-tag one\n+\t09e12a9 three\tsource-tag\n+\t8e393e1 two\tsource-a\n+\t1ac6c77 one\tsource-tag\n \tEOF\n \tgit log --oneline --source source-tag source-a >actual &&\n \ttest_cmp expect actual\ndiff --git a/t/t4207-log-decoration-colors.sh b/t/t4207-log-decoration-colors.sh\nindex b972296f06..08236a83e7 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 <\\\n+${c_commit}COMMIT_ID${c_reset} B${c_commit} (${c_reset}${c_HEAD}HEAD ->\\\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})${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_reset}${c_tag}tag: A${c_reset}${c_commit})${c_reset} A\n+ ${c_reset}${c_tag}tag: B${c_reset}${c_commit})${c_reset}\n+${c_commit}COMMIT_ID${c_reset} A1${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}\n+${c_commit}COMMIT_ID${c_reset} On master: Changes to A.t\\\n+${c_commit} (${c_reset}${c_stash}refs/stash${c_reset}${c_commit})${c_reset}\n+${c_commit}COMMIT_ID${c_reset} A${c_commit} (${c_reset}${c_tag}tag: A${c_reset}${c_commit})${c_reset}\n EOF\n \n # We want log to show all, but the second parent to refs/stash is irrelevant\n"},{"id":"311609","messageId":"20170215002901.gtzegvhyy7d6cvrb@sigill.intra.peff.net","threadId":"45115","inReplyTo":"xmqqr330779h.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-15T00:29:02Z","receivedAt":"2017-02-15T00:29:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 14, 2017 at 02:11:06PM -0800, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Thanks. We'd need to update the tests that expects the old style\n> > output, though.\n> \n> The updates to the expectation look like this (already squashed).\n> The --source decorations in 4202 are also shown at the end, which\n> probably is in line with the way --show-decorations adds them at the\n> end of the line, but was somewhat surprising from reading only the\n> log message.\n\nHrm, that does surprise me. I'm not sure if that's desirable or not. I\ndo think some of the \"nobody could possibly be parsing these\" arguments\nabout decorations do not apply to --source (and also, they're harder for\nhumans to pick out from the end of the line as they lack punctuation and\ncolor).\n\n-Peff\n"},{"id":"312024","messageId":"xmqqefywnk5a.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"20170215002901.gtzegvhyy7d6cvrb@sigill.intra.peff.net","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-18T05:27:29Z","receivedAt":"2017-02-18T05:35:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> The updates to the expectation look like this (already squashed).\n>> The --source decorations in 4202 are also shown at the end, which\n>> probably is in line with the way --show-decorations adds them at the\n>> end of the line, but was somewhat surprising from reading only the\n>> log message.\n>\n> Hrm, that does surprise me. I'm not sure if that's desirable or not. I\n> do think some of the \"nobody could possibly be parsing these\" arguments\n> about decorations do not apply to --source (and also, they're harder for\n> humans to pick out from the end of the line as they lack punctuation and\n> color).\n\nI just got bitten by a fallout. I have\n\n $ git recent --help\n `git recent' is aliased to `log --oneline --branches --no-merges \\\n\t --source --since=3.weeks'\n\nand often do\n\n $ git recent name-hash.c\n\nprimarily to see if I already queued a patch series to a topic (and\nforgot about it), and/or what other recent topics in flight touch\nthe same thing.\n\nI'd need that the topic name to be shown rather prominently for this\nuse case, i.e.\n\n eb2263adb1 jh/memihash-opt name-hash: remember previous dir_...\n 0c04267dc8 jh/memihash-opt name-hash: specify initial size f...\n 57463ce445 jh/memihash-opt name-hash: precompute hash values...\n dd3170e2cf jh/memihash-opt name-hash: eliminate duplicate me...\n\nbut now the branch names are shown at the end, which defeats the\nwhole point of the alias.\n\nIf nobody gets around to fixing it, I may take a look at it when\nable, but for now let me just vent^Wreport a regression first.\n"},{"id":"312098","messageId":"CA+55aFw3ZRtgsLGW-TFqpq-3uCw55L42p7cF=Q-73qM_VPuYsQ@mail.gmail.com","threadId":"45115","inReplyTo":"xmqqefywnk5a.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-19T22:33:02Z","receivedAt":"2017-02-19T22:33:08Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Feb 17, 2017 at 9:27 PM, Junio C Hamano wrote:\n>\n> I just got bitten by a fallout. I have\n>\n> $ git recent --help\n> `git recent' is aliased to `log --oneline --branches --no-merges \\\n> --source --since=3.weeks'\n>\n> but now the branch names are shown at the end, which defeats the\n> whole point of the alias.\n\nYes, your situation actually wants those decorations as primary\nthings, so having them at the end is indeed pointless.\n\nSo I think we should just discard that patch of mine.\n\n Linus\n"},{"id":"312099","messageId":"CA+P7+xqtPwzt3J6O05TP=E_hh-ko97adn+__Zmc0DNSDqEnEHw@mail.gmail.com","threadId":"45115","inReplyTo":"CA+55aFw3ZRtgsLGW-TFqpq-3uCw55L42p7cF=Q-73qM_VPuYsQ@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-02-19T23:03:21Z","receivedAt":"2017-02-19T23:03:49Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Feb 19, 2017 at 2:33 PM, Linus Torvalds\n wrote:\n> On Fri, Feb 17, 2017 at 9:27 PM, Junio C Hamano wrote:\n>>\n>> I just got bitten by a fallout. I have\n>>\n>> $ git recent --help\n>> `git recent' is aliased to `log --oneline --branches --no-merges \\\n>> --source --since=3.weeks'\n>>\n>> but now the branch names are shown at the end, which defeats the\n>> whole point of the alias.\n>\n> Yes, your situation actually wants those decorations as primary\n> things, so having them at the end is indeed pointless.\n>\n> So I think we should just discard that patch of mine.\n>\n> Linus\n\nI would think that in general putting them at the end makes more\nsense, but we should have the ability to use them in format specifiers\nso that users are free to customize it exactly how they want. That is,\nI agree with the reasoning presented in the original patch, but think\nJunio's case can be solved by strengthening the custom formats.\n\nThanks,\nJake\n"},{"id":"312121","messageId":"20170220004648.c2zz6bm2hylvep6x@sigill.intra.peff.net","threadId":"45115","inReplyTo":"CA+P7+xqtPwzt3J6O05TP=E_hh-ko97adn+__Zmc0DNSDqEnEHw@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-20T00:46:48Z","receivedAt":"2017-02-20T00:47:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 19, 2017 at 03:03:21PM -0800, Jacob Keller wrote:\n\n> >> I just got bitten by a fallout. I have\n> >>\n> >> $ git recent --help\n> >> `git recent' is aliased to `log --oneline --branches --no-merges \\\n> >> --source --since=3.weeks'\n> >>\n> >> but now the branch names are shown at the end, which defeats the\n> >> whole point of the alias.\n> >\n> > Yes, your situation actually wants those decorations as primary\n> > things, so having them at the end is indeed pointless.\n> >\n> > So I think we should just discard that patch of mine.\n> >\n> > Linus\n> \n> I would think that in general putting them at the end makes more\n> sense, but we should have the ability to use them in format specifiers\n> so that users are free to customize it exactly how they want. That is,\n> I agree with the reasoning presented in the original patch, but think\n> Junio's case can be solved by strengthening the custom formats.\n\nI think there are two potential patches:\n\n 1. Add a custom-format placeholder for the --source value.\n This is an obvious improvement that doesn't hurt anyone.\n\n 2. Switch --decorate to the end by default, but _not_ --source.\n\n This use case _could_ be served already by using a custom format\n with \"%d\". So it's really just a matter of having better-looking\n default.\n\n It might hurt somebody's script, but for the reasons discussed\n earlier in the thread, people are unlikely to be parsing it (it's\n more likely somebody would just complain because they think the\n decoration-first behavior is prettier).\n\n-Peff\n"},{"id":"312122","messageId":"xmqqr32tll22.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"20170220004648.c2zz6bm2hylvep6x@sigill.intra.peff.net","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-20T01:15:17Z","receivedAt":"2017-02-20T01:15:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think there are two potential patches:\n>\n> 1. Add a custom-format placeholder for the --source value.\n> This is an obvious improvement that doesn't hurt anyone.\n>\n> 2. Switch --decorate to the end by default, but _not_ --source.\n>\n> This use case _could_ be served already by using a custom format\n> with \"%d\". So it's really just a matter of having better-looking\n> default.\n\nYes, and I agree it is a better default to have \"--decorate\" at the\nend.\n\nI do not mind having to use a custom format myself, but I suspect\nthat the default for \"--source\" is more useful to have it at the\nbeginning, because \"--source\" annotates each and every commit, as\nopposed to \"--decorate\" that adds annotation few and far between.\n\n\n"},{"id":"312123","messageId":"CA+55aFwdUxCvmi28T3yn1K4rqn2bZmJBdTRr7tSbMa-g5izHbw@mail.gmail.com","threadId":"45115","inReplyTo":"20170220004648.c2zz6bm2hylvep6x@sigill.intra.peff.net","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-20T01:48:28Z","receivedAt":"2017-02-20T01:48:35Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Sun, Feb 19, 2017 at 4:46 PM, Jeff King wrote:\n>\n> I think there are two potential patches:\n>\n> 1. Add a custom-format placeholder for the --source value.\n> This is an obvious improvement that doesn't hurt anyone.\n\nRight.\n\n> 2. Switch --decorate to the end by default, but _not_ --source.\n\n.. and in fact the whole \"--source\" printing should not even have been\nmixed up with the decorations.\n\nSo (2) is actually easy to fix: just don't mix \"show_source()\" with\n\"show_decorations()\", because they are totally different things to\nbegin with.\n\nThat source showing should never have been in \"show_decorations()\" in\nthe first place. It just happened to be a convenient place for it.\n\nSo this attached patch is just my original patch updated to split up\n\"show_source()\" from \"show_decorations()\", and show it where it used\nto be.\n\nMaybe this works for Junio's alias?\n\n Linus\n\n\nFrom 97abab56fed451476f6ec676346b1e66001ef864 Mon Sep 17 00:00:00 2001\nFrom: Linus Torvalds \nDate: Sat, 11 Feb 2017 10:03:33 -0800\nSubject: [PATCH] show decorations at the end of the line\n\nSo I use \"--show-decorations\" all the time because I find it very useful\nto see where the origin branch is, where tags are etc. In fact, my global\ngit config file has\n\n [log]\n decorate = auto\n\nin it, so that I don't have to type it out all the time when I just do my\nusual 'git log\". It's lovely.\n\nHowever, it does make one particular case uglier: with commit decorations,\nthe \"oneline\" commit format ends up being not very pretty:\n\n [torvalds@i7 git]$ git log --oneline -10\n 3f07dac29 (HEAD -> master) pathspec: don't error out on all-exclusionary pathspec patterns\n ca4a562f2 pathspec magic: add '^' as alias for '!'\n 02555c1b2 ls-remote: add \"--diff\" option to show only refs that differ\n 6e3a7b339 (tag: v2.12.0-rc0, origin/master, origin/HEAD) Git 2.12-rc0\n fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'\n 74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'\n 36acf4123 Merge branch 'rs/object-id'\n ecc486b1f Merge branch 'js/re-running-failed-tests'\n 4ba6bb2d1 Merge branch 'sb/submodule-update-initial-runs-custom-script'\n 5348021c6 Merge branch 'sb/submodule-recursive-absorb'\n\nand note how the decoration comes right after the shortened commit hash,\nbreaking up the alignment of the messages.\n\nThe above doesn't show it with the colorization: I also have\n\n [color]\n ui=auto\n\nso on my terminal the decoration is also nicely colorized which makes it\nmuch more obvious, it's not as obvious in this message.\n\nThe oneline message handling is already pretty special, this makes it even\nmore special by putting the decorations at the end of the line:\n\n 3f07dac29 pathspec: don't error out on all-exclusionary pathspec patterns (HEAD -> master)\n ca4a562f2 pathspec magic: add '^' as alias for '!'\n 02555c1b2 ls-remote: add \"--diff\" option to show only refs that differ\n 6e3a7b339 Git 2.12-rc0 (tag: v2.12.0-rc0, origin/master, origin/HEAD)\n fafca0f72 Merge branch 'cw/log-updates-for-all-refs-really'\n 74dee5cfa Merge branch 'pl/complete-diff-submodule-diff'\n 36acf4123 Merge branch 'rs/object-id'\n ecc486b1f Merge branch 'js/re-running-failed-tests'\n 4ba6bb2d1 Merge branch 'sb/submodule-update-initial-runs-custom-script'\n 5348021c6 Merge branch 'sb/submodule-recursive-absorb'\n\nwhich looks a lot better (again, this is all particularly noticeable with\ncolorization).\n\nNOTE! There's a very special case for \"git log --oneline -g\" that shows\nthe reflogs as oneliners, and this does *not* fix that special case. It's\na lot more involved and relies on the exact show_reflog_message()\nimplementation, so I left the format for that alone, along with a comment\nabout how it's not at the end of line.\n\nSigned-off-by: Linus Torvalds \n---\n builtin/rev-list.c | 1 +\n log-tree.c | 17 ++++++++++++++---\n log-tree.h | 1 +\n 3 files changed, 16 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/rev-list.c b/builtin/rev-list.c\nindex 0aa93d589..8833f029a 100644\n--- a/builtin/rev-list.c\n+++ b/builtin/rev-list.c\n@@ -107,6 +107,7 @@ static void show_commit(struct commit *commit, void *data)\n \t\t\tchildren = children->next;\n \t\t}\n \t}\n+\tshow_source(revs, commit);\n \tshow_decorations(revs, commit);\n \tif (revs->commit_format == CMIT_FMT_ONELINE)\n \t\tputchar(' ');\ndiff --git a/log-tree.c b/log-tree.c\nindex 8c2415747..9ca3e8c1c 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -279,12 +279,16 @@ void format_decorations_extended(struct strbuf *sb,\n \tstrbuf_addstr(sb, color_reset);\n }\n \n+void show_source(struct rev_info *opt, struct commit *commit)\n+{\n+\tif (opt->show_source && commit->util)\n+\t\tfprintf(opt->diffopt.file, \"\\t%s\", (char *) commit->util);\n+}\n+\n void show_decorations(struct rev_info *opt, struct commit *commit)\n {\n \tstruct strbuf sb = STRBUF_INIT;\n \n-\tif (opt->show_source && commit->util)\n-\t\tfprintf(opt->diffopt.file, \"\\t%s\", (char *) commit->util);\n \tif (!opt->show_decorations)\n \t\treturn;\n \tformat_decorations(&sb, commit, opt->diffopt.use_color);\n@@ -556,6 +560,7 @@ void show_log(struct rev_info *opt)\n \t\t\tshow_parents(commit, abbrev_commit, opt->diffopt.file);\n \t\tif (opt->children.name)\n \t\t\tshow_children(opt, commit, abbrev_commit);\n+\t\tshow_source(opt, commit);\n \t\tshow_decorations(opt, commit);\n \t\tif (opt->graph && !graph_is_commit_finished(opt->graph)) {\n \t\t\tputc('\\n', opt->diffopt.file);\n@@ -622,10 +627,14 @@ void show_log(struct rev_info *opt)\n \t\t\t find_unique_abbrev(parent->object.oid.hash,\n \t\t\t\t\t\t abbrev_commit));\n \t\tfputs(diff_get_color_opt(&opt->diffopt, DIFF_RESET), opt->diffopt.file);\n-\t\tshow_decorations(opt, commit);\n+\t\tshow_source(opt, commit);\n \t\tif (opt->commit_format == CMIT_FMT_ONELINE) {\n+\t\t\t/* Not at end of line, but.. */\n+\t\t\tif (opt->reflog_info)\n+\t\t\t\tshow_decorations(opt, commit);\n \t\t\tputc(' ', opt->diffopt.file);\n \t\t} else {\n+\t\t\tshow_decorations(opt, commit);\n \t\t\tputc('\\n', opt->diffopt.file);\n \t\t\tgraph_show_oneline(opt->graph);\n \t\t}\n@@ -716,6 +725,8 @@ void show_log(struct rev_info *opt)\n \t\topt->missing_newline = 0;\n \n \tgraph_show_commit_msg(opt->graph, opt->diffopt.file, &msgbuf);\n+\tif (ctx.fmt == CMIT_FMT_ONELINE)\n+\t\tshow_decorations(opt, commit);\n \tif (opt->use_terminator && !commit_format_is_empty(opt->commit_format)) {\n \t\tif (!opt->missing_newline)\n \t\t\tgraph_show_padding(opt->graph);\ndiff --git a/log-tree.h b/log-tree.h\nindex c8116e60c..33d415820 100644\n--- a/log-tree.h\n+++ b/log-tree.h\n@@ -20,6 +20,7 @@ void format_decorations_extended(struct strbuf *sb, const struct commit *commit,\n \t\t\t const char *suffix);\n #define format_decorations(strbuf, commit, color) \\\n \t\t\t format_decorations_extended((strbuf), (commit), (color), \" (\", \", \", \")\")\n+void show_source(struct rev_info *opt, struct commit *commit);\n void show_decorations(struct rev_info *opt, struct commit *commit);\n void log_write_email_headers(struct rev_info *opt, struct commit *commit,\n \t\t\t const char **subject_p,\n-- \n2.12.0.rc2.4.g97abab56f\n\n"},{"id":"312219","messageId":"xmqqpoibfgo3.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"CA+55aFwdUxCvmi28T3yn1K4rqn2bZmJBdTRr7tSbMa-g5izHbw@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-21T20:11:08Z","receivedAt":"2017-02-21T20:11:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> That source showing should never have been in \"show_decorations()\" in\n> the first place. It just happened to be a convenient place for it.\n>\n> So this attached patch is just my original patch updated to split up\n> \"show_source()\" from \"show_decorations()\", and show it where it used\n> to be.\n\nThe updated organization smells a lot better to me ;-) \n\nMost of the time it is convenient to have \"show source\" at the\nbeginning of a single helper that is to show both, but oneline\nformat is so special that it makes it inconvenient to have them at\nthe same place.\n\nI can lose the patch to 4202 (update the expectation for --source)\nI added to the previous one, but the patch to 4207 (update the\nexpectation for --decorate) needs to be kept with this round.\n\nWill replace; thanks.\n"},{"id":"312222","messageId":"CA+55aFwT2HUBzZO8Gpt9tHoJtdRxv9oe3TDoSH5jcEOixRNBXg@mail.gmail.com","threadId":"45115","inReplyTo":"xmqqpoibfgo3.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2017-02-21T20:40:11Z","receivedAt":"2017-02-21T20:40:18Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Tue, Feb 21, 2017 at 12:11 PM, Junio C Hamano wrote:\n>\n> The updated organization smells a lot better to me ;-)\n\nSo I have been using the original patch for a bit over a week now, and\nI have to say that I'm not sure it's the right thing to do after all.\n\nMost of the time I much prefer the \"decorations at the end\" thing,\nbecause it just looks better, and the commit log oneliners line up\nnicely.\n\nBut then occasionally I end up liking the old interface better, just\nbecause there's long commit lines, and showing the decoration at the\nend effectively hides it.\n\nSo I vacillate between the two formats, and so I'm not sure this patch\nis worth the change in behavior after all.\n\nIn fact, I played around with some formats, and the one I lines the\nmost was actually one that split the line for decorations, but that\none was admittedly pretty funky. It gives output like\n\n b9df16a4c (HEAD -> master)\n pathspec: don't error out on all-exclusionary pathspec patterns\n 91a491f05 pathspec magic: add '^' as alias for '!'\n c8e05fd6d ls-remote: add \"--diff\" option to show only refs that differ\n 20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD)\n Git 2.12-rc2\n 076c05393 Hopefully the final batch of mini-topics before the final\n c5b22b819 Merge branch 'jk/tempfile-ferror-fclose-confusion'\n 62fef5c56 Merge branch 'dp/submodule-doc-markup-fix'\n 1f73ff080 Merge branch 'jk/reset-to-break-a-commit-doc-updated'\n bf5f11918 Merge branch 'jk/reset-to-break-a-commit-doc'\n e048a257b Merge branch 'js/mingw-isatty'\n\n(which looks better with colorization than it looks in the email).\n\nBut I'm not even going to send out that patch, because it was such an\natrocious hack to line things up.\n\n Linus\n"},{"id":"312226","messageId":"20170221210808.3ryri33ve7w7csdp@sigill.intra.peff.net","threadId":"45115","inReplyTo":"CA+55aFwT2HUBzZO8Gpt9tHoJtdRxv9oe3TDoSH5jcEOixRNBXg@mail.gmail.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-21T21:08:08Z","receivedAt":"2017-02-21T21:08:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 21, 2017 at 12:40:11PM -0800, Linus Torvalds wrote:\n\n> In fact, I played around with some formats, and the one I lines the\n> most was actually one that split the line for decorations, but that\n> one was admittedly pretty funky. It gives output like\n> \n> b9df16a4c (HEAD -> master)\n> pathspec: don't error out on all-exclusionary pathspec patterns\n> 91a491f05 pathspec magic: add '^' as alias for '!'\n> c8e05fd6d ls-remote: add \"--diff\" option to show only refs that differ\n> 20769079d (tag: v2.12.0-rc2, origin/master, origin/HEAD)\n> Git 2.12-rc2\n> 076c05393 Hopefully the final batch of mini-topics before the final\n> c5b22b819 Merge branch 'jk/tempfile-ferror-fclose-confusion'\n> 62fef5c56 Merge branch 'dp/submodule-doc-markup-fix'\n> 1f73ff080 Merge branch 'jk/reset-to-break-a-commit-doc-updated'\n> bf5f11918 Merge branch 'jk/reset-to-break-a-commit-doc'\n> e048a257b Merge branch 'js/mingw-isatty'\n> \n> (which looks better with colorization than it looks in the email).\n> \n> But I'm not even going to send out that patch, because it was such an\n> atrocious hack to line things up.\n\nI was going to suggest a custom format string that does the same, but\nwhat we have is not _quite_ flexible enough.\n\nYou can use \"%+d\" to insert a newline only when \"%d\" is not empty. But\nit always inserts _before_ the decoration, not after. Likewise, you\ncannot say \"if it's not empty, then insert %d and a leading tab\".\n\nThe for-each-ref formatting code has %(if), but it's not unified with\nthe commit-format ones.\n\nSo the best I could come up with is:\n\n git config pretty.twoline '%C(auto)%h %s%C(auto)%+d'\n git log --format=twoline\n\nwhich looks like:\n\n 80ba04ed9 Merge branch 'svn-escape-backslash' of git://bogomips.org/git-svn\n (origin/master, origin/HEAD)\n 20769079d Git 2.12-rc2\n (tag: v2.12.0-rc2)\n 076c05393 Hopefully the final batch of mini-topics before the final\n c5b22b819 Merge branch 'jk/tempfile-ferror-fclose-confusion'\n 62fef5c56 Merge branch 'dp/submodule-doc-markup-fix'\n 1f73ff080 Merge branch 'jk/reset-to-break-a-commit-doc-updated'\n\n-Peff\n"},{"id":"312228","messageId":"xmqq8tozfc7a.fsf@gitster.mtv.corp.google.com","threadId":"45115","inReplyTo":"20170221210808.3ryri33ve7w7csdp@sigill.intra.peff.net","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-21T21:47:37Z","receivedAt":"2017-02-21T21:47:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The for-each-ref formatting code has %(if), but it's not unified with\n> the commit-format ones.\n>\n> So the best I could come up with is:\n>\n> git config pretty.twoline '%C(auto)%h %s%C(auto)%+d'\n> git log --format=twoline\n>\n> which looks like:\n>\n> 80ba04ed9 Merge branch 'svn-escape-backslash' of git://bogomips.org/git-svn\n> (origin/master, origin/HEAD)\n> 20769079d Git 2.12-rc2\n> (tag: v2.12.0-rc2)\n> 076c05393 Hopefully the final batch of mini-topics before the final\n> c5b22b819 Merge branch 'jk/tempfile-ferror-fclose-confusion'\n> 62fef5c56 Merge branch 'dp/submodule-doc-markup-fix'\n> 1f73ff080 Merge branch 'jk/reset-to-break-a-commit-doc-updated'\n\nYeah, I had a similar thought to use something around \"%n%-d\", but\n\n $ git log --format='%h%n%-d%C(auto) %s %C(auto)'\n\nis not it.\n\nI guess we could pile on another hack to make the sign between % and\nthe format specifier cumulative and then \"%n%-+d\" may do what we\nwant, but we need a true %(if)...%(then)...%(else)...%(end) support\nif we really want to do this thing properly.\n"},{"id":"312232","messageId":"20170221222451.kiuyrp3raufhvkte@sigill.intra.peff.net","threadId":"45115","inReplyTo":"xmqq8tozfc7a.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] show decorations at the end of the line","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-21T22:24:51Z","receivedAt":"2017-02-21T22:24:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 21, 2017 at 01:47:37PM -0800, Junio C Hamano wrote:\n\n> > So the best I could come up with is:\n> >\n> > git config pretty.twoline '%C(auto)%h %s%C(auto)%+d'\n> > git log --format=twoline\n> > [...]\n>\n> Yeah, I had a similar thought to use something around \"%n%-d\", but\n> \n> $ git log --format='%h%n%-d%C(auto) %s %C(auto)'\n> \n> is not it.\n> \n> I guess we could pile on another hack to make the sign between % and\n> the format specifier cumulative and then \"%n%-+d\" may do what we\n> want, but we need a true %(if)...%(then)...%(else)...%(end) support\n> if we really want to do this thing properly.\n\nYeah, I'd rather not pile up more hacks. The for-each-ref placeholders\nare more verbose, but I think the end result is a lot easier to read and\nmaintain, and the terseness doesn't matter if you're sticking it behind\nan alias or config option.\n\n(Don't get me wrong; I think the %(if) ones are pretty ugly, too, but\nthe next step beyond that is embedding some kind of templating or\nscripting language, and that just seems like overkill).\n\n-Peff\n"}]}