{"thread":{"id":"17595","subject":"[ANNOUNCE] tig-0.14","startedAt":"2009-02-05T20:44:36Z","lastAt":"2009-02-25T21:54:38Z","messageCount":69,"participants":["Jonas Fonseca","bill lam","Sitaram Chamarty","Jeff King","Jakub Narebski","Mikael Magnusson","Junio C Hamano","david@lang.hm","Peter Baumann","Ted Pavlic","Brian Gernhardt","Stefan Karpinski","Jari Aalto","Tilo Schwarz","Thomas Adam","Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"103384","messageId":"20090205204436.GA6072@diku.dk","threadId":"17595","inReplyTo":null,"subject":"[ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-05T20:44:36Z","receivedAt":"2009-02-05T20:44:36Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Hello,\n\nHere is a much needed update fixing multiple regressions from the\nintroduction of the IO API in 0.13. Among improvements is the much\nrequested ability to restore the position in the stage view when staging\ndiff hunks. Also noteworthy is the many optimizations of the screen\nupdating to make it work better across slow links. Finally, beware that\na handful of incompatibilities can cause problems.\n\nWhat is tig?\n------------\nTig is an ncurses-based text-mode interface for git. It functions mainly\nas a git repository browser, but can also assist in staging changes for\ncommit at chunk level and act as a pager for output from various git\ncommands.\n\n - Homepage:\thttp://jonas.nitro.dk/tig/\n - Manual:\thttp://jonas.nitro.dk/tig/manual.html\n - Tarballs:\thttp://jonas.nitro.dk/tig/releases/\n - Git URL:\tgit://repo.or.cz/tig.git \n - Gitweb:\thttp://repo.or.cz/w/tig.git\n\nRelease notes\n-------------\nIncompatibilities:\n\n - The screen-resize action has been deprecated. It had no real use for\n users and was never meant to be exposed.\n - The \"tree-parent\" action was renamed to \"parent\". Warnings will be\n emitted for transition.\n - Remove parsing of deprecated option -S and subcommands log and diff.\n - The \"author\" color replaces \"main-author\". Setting the latter will\n now set the \"author\" color.\n\nImprovements:\n\n - Horizontal scrolling. Bound to Left/Right by default.\n - Read tigrc(5) options from git configuration files using the syntax:\n\n\t[tig] show-rev-graph = true\n\t[tig \"color\"] cursor = yellow red bold \n\t[tig \"bind\"] generic = P parent\n\n - Tree view: avoid flickering when updating.\n - Tree view: annotate entries with commit information.\n - Tree & blob view: open any blob in an editor.\n - Stage & main view: restore view position when reloading.\n - Blame view: load blame for parent commit. For merge commits the parent\n is queried. Bound to ',' by default via the existing \"parent\" action.\n - Abbreviate author names to initials when the width of the author column\n is below 6 characters.\n\nBug fixes:\n\n - Tree view: fix memory corruption bug when updating.\n - Tree view: improve handling of empty trees.\n - Status view: fix reverting of unmerged files.\n - Fix regression for non-UTF-8 locales corrupting the view data.\n - Fix regression parsing multiple spaces in ~/.tigrc.\n\nChange summary\n--------------\nThe diffstat and log summary for changes made in this release.\n\n BUGS | 2 -\n INSTALL | 2 +-\n Makefile | 22 +-\n NEWS | 43 +-\n TODO | 58 +-\n VERSION | 2 +-\n contrib/aspell.dict | 147 ++++\n contrib/release.sh | 75 ++\n manual.txt | 48 +-\n tig.1.txt | 14 +-\n tig.c | 1784 +++++++++++++++++++++++++++----------------\n tigrc.5.txt | 91 ++-\n 12 files changed, 1520 insertions(+), 768 deletions(-)\n\n 1\tJeff King\n 76\tJonas Fonseca\n 1\tStefan Naewe\n\n-- \nJonas Fonseca\n"},{"id":"103447","messageId":"20090206104946.GE7259@b2j","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-02-06T10:49:46Z","receivedAt":"2009-02-06T10:49:46Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"Thank you for the update!\n\nThere is a choice in \"git add -i\" call patch/hunks. Is this the same\nas the update/chunks as described in tig manual?\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n唐詩110 杜甫 天末懷李白\n 涼風起天末 君子意如何 鴻雁幾時到 江湖秋水多\n 文章憎命達 魑魅喜人過 應共冤魂語 投詩贈汨羅\n"},{"id":"103486","messageId":"2c6b72b30902060629i2539ddds48ab858e83d4bb4@mail.gmail.com","threadId":"17595","inReplyTo":"20090206104946.GE7259@b2j","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-06T14:29:04Z","receivedAt":"2009-02-06T14:29:04Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"2009/2/6 bill lam :\n> There is a choice in \"git add -i\" call patch/hunks. Is this the same\n> as the update/chunks as described in tig manual?\n\nYes, you can stage individual path hunks (I should probably use the\ngit terminology) using 'u' in the stage view. Use '@' to navigate to\nthe next path hunk.\n\nTwo things tig does not (yet) support is splitting and editing a hunk.\n\n-- \nJonas Fonseca\n"},{"id":"103501","messageId":"slrngooljv.urh.sitaramc@sitaramc.homelinux.net","threadId":"17595","inReplyTo":"2c6b72b30902060629i2539ddds48ab858e83d4bb4@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-06T15:25:51Z","receivedAt":"2009-02-06T15:25:51Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-06, Jonas Fonseca wrote:\n> Two things tig does not (yet) support is splitting and editing a hunk.\n\nBut I must say that the last time I did this, the hunks that\ntig showed me were more granular than what 'git gui' did; no\nidea why. To do what I wanted to do in 'git gui' was\npossible, by staging line by line instead of hunk by hunk,\nbut I didn't fancy all that clicking and tig saved me.\n\nSo... thanks!\n"},{"id":"103544","messageId":"20090206191511.GD19494@coredump.intra.peff.net","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-06T19:15:11Z","receivedAt":"2009-02-06T19:15:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:\n\n> - Blame view: load blame for parent commit. For merge commits the parent\n> is queried. Bound to ',' by default via the existing \"parent\" action.\n\nThanks for this, btw. I've already used it at least half a dozen times\nin the past week or so.\n\nIt looks like you just keep the view on the same line number when moving\nto the new blame output. In practice, this has very mixed results. Most\nof the time it does exactly what I want, but if the file changes\nsignificantly, you get dumped at a totally unrelated part of the file.\nI'm not sure if there is a more clever solution, though.\n\n-Peff\n"},{"id":"103565","messageId":"2c6b72b30902061410l64c98c33g19b97f656d347c83@mail.gmail.com","threadId":"17595","inReplyTo":"20090206191511.GD19494@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-06T22:10:23Z","receivedAt":"2009-02-06T22:10:23Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Fri, Feb 6, 2009 at 20:15, Jeff King wrote:\n> On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:\n>\n>> - Blame view: load blame for parent commit. For merge commits the parent\n>> is queried. Bound to ',' by default via the existing \"parent\" action.\n>\n> Thanks for this, btw. I've already used it at least half a dozen times\n> in the past week or so.\n\nGood to hear. I remember you posted a patch for this after 0.11 was\nreleased last April.\n\n> It looks like you just keep the view on the same line number when moving\n> to the new blame output. In practice, this has very mixed results. Most\n> of the time it does exactly what I want, but if the file changes\n> significantly, you get dumped at a totally unrelated part of the file.\n> I'm not sure if there is a more clever solution, though.\n\nYes, it is a bit easy to get lost. It should be possible to find the\noriginal line number either by making git-blame also honor\n--show-number for the --incremental output or by using the \"porcelain\"\nversion:\n\n git blame --show-number -L , \n\n-- \nJonas Fonseca\n"},{"id":"103567","messageId":"m3r62buqiv.fsf@localhost.localdomain","threadId":"17595","inReplyTo":"2c6b72b30902061410l64c98c33g19b97f656d347c83@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-02-06T22:53:02Z","receivedAt":"2009-02-06T22:53:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonas Fonseca writes:\n\n> On Fri, Feb 6, 2009 at 20:15, Jeff King wrote:\n> > On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:\n>>\n>>> - Blame view: load blame for parent commit. For merge commits the parent\n>>> is queried. Bound to ',' by default via the existing \"parent\" action.\n\n>> It looks like you just keep the view on the same line number when moving\n>> to the new blame output. In practice, this has very mixed results. Most\n>> of the time it does exactly what I want, but if the file changes\n>> significantly, you get dumped at a totally unrelated part of the file.\n>> I'm not sure if there is a more clever solution, though.\n> \n> Yes, it is a bit easy to get lost. It should be possible to find the\n> original line number either by making git-blame also honor\n> --show-number for the --incremental output or by using the \"porcelain\"\n> version:\n> \n> git blame --show-number -L , \n\nErrr... you are wrong. There are three line numbers when browsing\nblame output. Original line number, line number in _blamed_ commit\n(shown with --show-number, --porcelain, --incremental), and line\nnumber in _parent_ of blamed commit... which we don't know, and\nwhich I don't think it is easy to find...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"103577","messageId":"237967ef0902061848g14765b5an6397901c4e81b048@mail.gmail.com","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2009-02-07T02:48:27Z","receivedAt":"2009-02-07T02:48:27Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2009/2/5 Jonas Fonseca :\n> Hello,\n>\n> Here is a much needed update fixing multiple regressions from the\n> introduction of the IO API in 0.13. Among improvements is the much\n> requested ability to restore the position in the stage view when staging\n> diff hunks. Also noteworthy is the many optimizations of the screen\n> updating to make it work better across slow links. Finally, beware that\n> a handful of incompatibilities can cause problems.\n\nI'm having a problem with tig taking 2 seconds to start up, which\nseems to be related to the 'typo checking' feature of git. After\nfiguring out how to stop strace from helpfully saying\nwrite(2, \"WARNING: You called a Git program\"..., 137) = 137\nI got this (with -s 100):\n[pid 29708] write(2, \"WARNING: You called a Git program named 'git\nconfig', which does not exist.\\nContinuing under the assu\"..., 137) =\n137\n[pid 29708] write(2, \"in 2.0 seconds automatically...\\n\"..., 32) = 32\n\nThe output however also contains lots of git config strings, which is\nconfusing. Is tig running git config twice and failing one of the\ntimes? (Running git config from the cmdline works fine).\n\n-- \nMikael Magnusson\n"},{"id":"103588","messageId":"20090207071056.GB14856@coredump.intra.peff.net","threadId":"17595","inReplyTo":"2c6b72b30902061410l64c98c33g19b97f656d347c83@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-07T07:10:56Z","receivedAt":"2009-02-07T07:10:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 06, 2009 at 11:10:23PM +0100, Jonas Fonseca wrote:\n\n> > It looks like you just keep the view on the same line number when moving\n> > to the new blame output. In practice, this has very mixed results. Most\n> > of the time it does exactly what I want, but if the file changes\n> > significantly, you get dumped at a totally unrelated part of the file.\n> > I'm not sure if there is a more clever solution, though.\n> \n> Yes, it is a bit easy to get lost. It should be possible to find the\n> original line number either by making git-blame also honor\n> --show-number for the --incremental output or by using the \"porcelain\"\n> version:\n> \n> git blame --show-number -L , \n\nI'm not sure that will always work. You know that in some version of the\nfile, line number X is of interest to you. You want to find the \"same\"\nspot in the parent commit. So you can:\n\n 1. use the line number in the blamed file; this doesn't work because\n the re-blamed file may have much more or less content before X,\n which is going to shift the content of interest.\n\n 2. use the line number that the content was introduced on in the blamed\n commit. This has the same problem as above, but may be more\n accurate because you are only jumping _one_ revision to the parent\n of the blamed commit (instead of from wherever you started\n blaming).\n\nMy impression is that tig is currently doing (1). I think (2) will\nsuffer from the same problem, but in practice the margin of error will\nbe much smaller because your are rewinding through fewer changes. So if\nthat is what you were suggesting, I think it is probably worth trying.\n\nIt would require a \"reload and jump to this arbitrary line\" function,\nwhich I remember being problematic when I did my original patch a long\ntime ago. But I haven't looked at the new code to see if it is easier\nnow (it looks like you have been doing quite a bit of refactoring in\nthat area lately).\n\nYou could also try matching up content, but that is equally error-prone.\nYou can't find the same line in the parent, for the obvious reason that\nyou've just blamed it, so by definition it doesn't exist in the parent.\nYou could try doing a fuzzy match on the surrounding blamed lines, but\nthere is no guarantee that they exist in the parent commit, either. So I\nthink the line number guess is probably our best bet.\n\n-Peff\n"},{"id":"103590","messageId":"7vprhuzoxm.fsf@gitster.siamese.dyndns.org","threadId":"17595","inReplyTo":"20090207071056.GB14856@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-07T07:28:05Z","receivedAt":"2009-02-07T07:28:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> My impression is that tig is currently doing (1). I think (2) will\n> suffer from the same problem, but in practice the margin of error will\n> be much smaller because your are rewinding through fewer changes. So if\n> that is what you were suggesting, I think it is probably worth trying.\n\nIt has been quite a while since I did the \"show previous\" feature of\n\"git-blame --porcelain\" that has been forever queued in 'next'; if I\nremember correctly, it implemented (2).\n\nThe reason why it never graduated from 'next' is exactly this issue. By\ndefinition, there is no \"previous\" line number (if there were such a thing\nthat says \"This line was at line N in the parent of the blamed commit\",\nthen the commit wouldn't have taken the blame but would have passed it\ndown to the parent), and we need to come up with a reasonable heuristics.\n\nSo perhaps this discussion would motivate somebody to finish that part\noff, and tig and other Porcelains can just read the necessary line number\nfrom the git-blame output.\n"},{"id":"103595","messageId":"alpine.DEB.1.10.0902070050490.8086@asgard.lang.hm","threadId":"17595","inReplyTo":"7vprhuzoxm.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-02-07T08:55:18Z","receivedAt":"2009-02-07T08:55:18Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 6 Feb 2009, Junio C Hamano wrote:\n\n> Jeff King writes:\n>\n>> My impression is that tig is currently doing (1). I think (2) will\n>> suffer from the same problem, but in practice the margin of error will\n>> be much smaller because your are rewinding through fewer changes. So if\n>> that is what you were suggesting, I think it is probably worth trying.\n>\n> It has been quite a while since I did the \"show previous\" feature of\n> \"git-blame --porcelain\" that has been forever queued in 'next'; if I\n> remember correctly, it implemented (2).\n>\n> The reason why it never graduated from 'next' is exactly this issue. By\n> definition, there is no \"previous\" line number (if there were such a thing\n> that says \"This line was at line N in the parent of the blamed commit\",\n> then the commit wouldn't have taken the blame but would have passed it\n> down to the parent), and we need to come up with a reasonable heuristics.\n>\n> So perhaps this discussion would motivate somebody to finish that part\n> off, and tig and other Porcelains can just read the necessary line number\n> from the git-blame output.\n\nthis sounds like the same basic problem I was having around the begninning \nof the year (thread subject 'how to track the history of a line in a \nfile') what I ended up doing was to use git blame to go back and find the \ncommit where a line was introduced, then use git diff to find the changes, \nthen find the hunk of the diff that introduced the line, then find the \nlines that were removed and trace them back (repeating the process)\n\nDavid Lang\n"},{"id":"103609","messageId":"20090207112613.GA18079@coredump.intra.peff.net","threadId":"17595","inReplyTo":"7vprhuzoxm.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-07T11:26:14Z","receivedAt":"2009-02-07T11:26:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 06, 2009 at 11:28:05PM -0800, Junio C Hamano wrote:\n\n> It has been quite a while since I did the \"show previous\" feature of\n> \"git-blame --porcelain\" that has been forever queued in 'next'; if I\n> remember correctly, it implemented (2).\n> \n> The reason why it never graduated from 'next' is exactly this issue. By\n> definition, there is no \"previous\" line number (if there were such a thing\n> that says \"This line was at line N in the parent of the blamed commit\",\n> then the commit wouldn't have taken the blame but would have passed it\n> down to the parent), and we need to come up with a reasonable heuristics.\n> \n> So perhaps this discussion would motivate somebody to finish that part\n> off, and tig and other Porcelains can just read the necessary line number\n> from the git-blame output.\n\nDo we actually have heuristics that are better than \"this was the line\nin the original source file?\" (i.e., (2) as I described). Because we\nalready have that in the first number that comes from \"blame\n--incremental\". So perhaps we should start using it and see how well it\nworks in practice (because like all heuristics, getting a good one is\nlikely to be a lot of guess and check on what works in practice).\n\nOf course I say \"we\" and I mean \"Jonas\". ;) I worked up a small tig\npatch below which seems to work, but:\n\n 1. the \"jump to this new line number on refresh\" code is very hack-ish\n (read: it is now broken for every view except blame), and I'm not\n sure of the most tig-ish way of fixing it\n\n 2. I'm very unsure of the line number parsing. The parse_number\n function confusingly parses \" 123 456\" as \"456\". So perhaps there\n is some invariant of the parsing strategy that I don't understand\n (like our pointer is supposed to be at the last character of the\n previous token and _not_ on the space). So the parsing in\n parse_blame_commit is a bit hack-ish.\n\n 3. Nothing in tig records the file that the source line came from. So\n we could be jumping to an arbitrary line number that really came\n from some other file.\n\nAnyway, here it is.\n\n---\ndiff --git a/tig.c b/tig.c\nindex 97794b0..faec056 100644\n--- a/tig.c\n+++ b/tig.c\n@@ -38,6 +38,7 @@\n #include \n #include \n #include \n+#include \n \n #include \n \n@@ -2574,7 +2575,7 @@ reset_view(struct view *view)\n \n \tview->p_offset = view->offset;\n \tview->p_yoffset = view->yoffset;\n-\tview->p_lineno = view->lineno;\n+\t/* view->p_lineno = view->lineno; */\n \n \tview->line = NULL;\n \tview->offset = 0;\n@@ -4180,6 +4181,7 @@ struct blame_commit {\n \n struct blame {\n \tstruct blame_commit *commit;\n+\tint lineno;\n \tchar text[1];\n };\n \n@@ -4243,14 +4245,16 @@ parse_blame_commit(struct view *view, const char *text, int *blamed)\n {\n \tstruct blame_commit *commit;\n \tstruct blame *blame;\n-\tconst char *pos = text + SIZEOF_REV - 1;\n+\tconst char *pos = text + SIZEOF_REV - 2;\n \tsize_t lineno;\n \tsize_t group;\n+\tsize_t orig_lineno;\n \n-\tif (strlen(text) <= SIZEOF_REV || *pos != ' ')\n+\tif (strlen(text) <= SIZEOF_REV || pos[1] != ' ')\n \t\treturn NULL;\n \n-\tif (!parse_number(&pos, &lineno, 1, view->lines) ||\n+\tif (!parse_number(&pos, &orig_lineno, 1, INT_MAX) ||\n+\t !parse_number(&pos, &lineno, 1, view->lines) ||\n \t !parse_number(&pos, &group, 1, view->lines - lineno + 1))\n \t\treturn NULL;\n \n@@ -4264,6 +4268,7 @@ parse_blame_commit(struct view *view, const char *text, int *blamed)\n \n \t\tblame = line->data;\n \t\tblame->commit = commit;\n+\t\tblame->lineno = orig_lineno + group - 1;\n \t\tline->dirty = 1;\n \t}\n \n@@ -4425,8 +4430,10 @@ blame_request(struct view *view, enum request request, struct line *line)\n \n \tcase REQ_PARENT:\n \t\tif (check_blame_commit(blame) &&\n-\t\t select_commit_parent(blame->commit->id, opt_ref))\n+\t\t select_commit_parent(blame->commit->id, opt_ref)) {\n+\t\t\tview->p_lineno = blame->lineno;\n \t\t\topen_view(view, REQ_VIEW_BLAME, OPEN_REFRESH);\n+\t\t}\n \t\tbreak;\n \n \tcase REQ_ENTER:\n"},{"id":"103714","messageId":"2c6b72b30902080207m4a1e14b7j4862f9a8b7ca32a9@mail.gmail.com","threadId":"17595","inReplyTo":"slrngooljv.urh.sitaramc@sitaramc.homelinux.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-08T10:07:30Z","receivedAt":"2009-02-08T10:07:30Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty wrote:\n> On 2009-02-06, Jonas Fonseca wrote:\n>> Two things tig does not (yet) support is splitting and editing a hunk.\n>\n> But I must say that the last time I did this, the hunks that\n> tig showed me were more granular than what 'git gui' did; no\n> idea why. To do what I wanted to do in 'git gui' was\n> possible, by staging line by line instead of hunk by hunk,\n> but I didn't fancy all that clicking and tig saved me.\n\nGreat to hear. I sometimes, miss though, being able to lower the diff\ncontext to 1 or 2, however, maybe I should learn to commit more often\ninstead.\n\n-- \nJonas Fonseca\n"},{"id":"103715","messageId":"2c6b72b30902080213v48b8420do2d53ddf6fda09aa1@mail.gmail.com","threadId":"17595","inReplyTo":"m3r62buqiv.fsf@localhost.localdomain","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T10:13:42Z","receivedAt":"2009-02-08T10:13:42Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Fri, Feb 6, 2009 at 23:53, Jakub Narebski wrote:\n> Jonas Fonseca writes:\n>> It should be possible to find the\n>> original line number either by making git-blame also honor\n>> --show-number for the --incremental output or by using the \"porcelain\"\n>> version:\n>>\n>> git blame --show-number -L , \n>\n> Errr... you are wrong. There are three line numbers when browsing\n> blame output. Original line number, line number in _blamed_ commit\n> (shown with --show-number, --porcelain, --incremental), and line\n> number in _parent_ of blamed commit... which we don't know, and\n> which I don't think it is easy to find...\n\nYes, I was not aware of the original line number being there. Anyway,\ntig now uses this to jump to the right line when the user requests to\nshow blame for specific commit.\n\n-- \nJonas Fonseca\n"},{"id":"103718","messageId":"2c6b72b30902080231i3f550322s106e1be2e5a4ed@mail.gmail.com","threadId":"17595","inReplyTo":"20090207071056.GB14856@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T10:31:43Z","receivedAt":"2009-02-08T10:31:43Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Sat, Feb 7, 2009 at 08:10, Jeff King wrote:\n> It would require a \"reload and jump to this arbitrary line\" function,\n> which I remember being problematic when I did my original patch a long\n> time ago. But I haven't looked at the new code to see if it is easier\n> now (it looks like you have been doing quite a bit of refactoring in\n> that area lately).\n\nYes, support for restoring/jumping to an arbitrary line is possible by\nsetting the view lineno and then call open_view with the OPEN_REFRESH\nflag.\n\n-- \nJonas Fonseca\n"},{"id":"103720","messageId":"2c6b72b30902080247n31e5c532m31006fcb07ca95da@mail.gmail.com","threadId":"17595","inReplyTo":"alpine.DEB.1.10.0902070050490.8086@asgard.lang.hm","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T10:47:49Z","receivedAt":"2009-02-08T10:47:49Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Sat, Feb 7, 2009 at 09:55, wrote:\n> On Fri, 6 Feb 2009, Junio C Hamano wrote:\n>> Jeff King writes:\n>>> My impression is that tig is currently doing (1). I think (2) will\n>>> suffer from the same problem, but in practice the margin of error will\n>>> be much smaller because your are rewinding through fewer changes. So if\n>>> that is what you were suggesting, I think it is probably worth trying.\n\nTig wasn't using the line number or even the filename, this has now been fixed.\n\n>> It has been quite a while since I did the \"show previous\" feature of\n>> \"git-blame --porcelain\" that has been forever queued in 'next'; if I\n>> remember correctly, it implemented (2).\n>>\n>> The reason why it never graduated from 'next' is exactly this issue. By\n>> definition, there is no \"previous\" line number (if there were such a thing\n>> that says \"This line was at line N in the parent of the blamed commit\",\n>> then the commit wouldn't have taken the blame but would have passed it\n>> down to the parent), and we need to come up with a reasonable heuristics.\n\nSo it ist somewhat safe to assume that the line didn't originate from\na different file, since git-blame would have picked that up?\n\n> this sounds like the same basic problem I was having around the begninning\n> of the year (thread subject 'how to track the history of a line in a file')\n> what I ended up doing was to use git blame to go back and find the commit\n> where a line was introduced, then use git diff to find the changes, then\n> find the hunk of the diff that introduced the line, then find the lines that\n> were removed and trace them back (repeating the process)\n\nI've tried to implement something like this by using the output of\n\"git-diff-tree -U0\". One problem it does not yet handle is the\ncut'n'paste within the same file where the deleted line ends up in a\ndifferent hunk. So it won't jump to the correct place if you try to\ntrace back for example the origin of the parse_options function in\ntig.c since at some point I moved it down in the file. However, it\ndoes work quite well for tracing back the origin of for example the\nDATE_COLS macro which was rewritten a few times.\n\nI guess it comes down to what you can assume about the features or\n\"uniqueness\" of the line (or lines) that are being traced back and\nwhether the history and commits are well organized.\n\n-- \nJonas Fonseca\n"},{"id":"103723","messageId":"2c6b72b30902080255w6ccac5e9vcd961a9ab93dcdf3@mail.gmail.com","threadId":"17595","inReplyTo":"2c6b72b30902080247n31e5c532m31006fcb07ca95da@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T10:55:55Z","receivedAt":"2009-02-08T10:55:55Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca wrote:\n> One problem it does not yet handle is the\n> cut'n'paste within the same file where the deleted line ends up in a\n> different hunk.\n\nHmm, this is trivially fixed by passing -M to git blame so maybe that\nshould just be the default for tig.\n\n-- \nJonas Fonseca\n"},{"id":"103726","messageId":"20090208110042.GA14359@coredump.intra.peff.net","threadId":"17595","inReplyTo":"2c6b72b30902080231i3f550322s106e1be2e5a4ed@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-08T11:00:42Z","receivedAt":"2009-02-08T11:00:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 08, 2009 at 11:31:43AM +0100, Jonas Fonseca wrote:\n\n> On Sat, Feb 7, 2009 at 08:10, Jeff King wrote:\n> > It would require a \"reload and jump to this arbitrary line\" function,\n> > which I remember being problematic when I did my original patch a long\n> > time ago. But I haven't looked at the new code to see if it is easier\n> > now (it looks like you have been doing quite a bit of refactoring in\n> > that area lately).\n> \n> Yes, support for restoring/jumping to an arbitrary line is possible by\n> setting the view lineno and then call open_view with the OPEN_REFRESH\n> flag.\n\nI just tried out the version you pushed today (which has both the\ncleaner version of my patch and the guesstimation patch). It behaves\nexactly as I would expect. Thanks so much for looking into this.\n\nI do have one more complaint, though. :)\n\nIf you parent-blame far enough, you will reach a point before the file\nexisted at all, in which case blame_read_file will die() with an error.\nIt would be nice to print an error and stay on the same screen. Below is\na patch which implements (I think) reasonably elegant solution.\n\n-- >8 --\nhandle blaming beyond the creation of file more gracefully\n\nCurrently when you ask to re-blame from the parent of a\ncommit that created the file, blame_read_file will complain\nthat it cannot get the file contents (\"No blame exist\").\n\nAt the time we try to read the file, it is too late to abort\nthe operation, as we have already changed to the new blame\nview. However, we can detect this situation early by\nlimiting the selection of the parent revision to the\nparticular path of interest: if it returns a parent even\nwith path-limiting, then we know the path exists; if not,\nthen we know it doesn't.\n\nSigned-off-by: Jeff King \n---\n tig.c | 12 ++++++++----\n 1 files changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/tig.c b/tig.c\nindex 04a44db..28fae2c 100644\n--- a/tig.c\n+++ b/tig.c\n@@ -3384,11 +3384,11 @@ select_commit_parent_handler(void *data, char *buf, int c)\n }\n \n static bool\n-select_commit_parent(const char *id, char rev[SIZEOF_REV])\n+select_commit_parent(const char *id, char rev[SIZEOF_REV], const char *path)\n {\n \tchar buf[SIZEOF_STR * 4];\n \tconst char *revlist_argv[] = {\n-\t\t\"git\", \"rev-list\", \"-1\", \"--parents\", id, NULL\n+\t\t\"git\", \"rev-list\", \"-1\", \"--parents\", id, \"--\", path, NULL\n \t};\n \tint parents;\n \n@@ -3399,7 +3399,10 @@ select_commit_parent(const char *id, char rev[SIZEOF_REV])\n \t\treturn FALSE;\n \n \t} else if (parents == 0) {\n-\t\treport(\"The selected commit has no parents\");\n+\t\tif (path)\n+\t\t\treport(\"path '%s' does not exist in the parent\", path);\n+\t\telse\n+\t\t\treport(\"The selected commit has no parents\");\n \t\treturn FALSE;\n \t}\n \n@@ -4468,7 +4471,8 @@ blame_request(struct view *view, enum request request, struct line *line)\n \n \tcase REQ_PARENT:\n \t\tif (check_blame_commit(blame) &&\n-\t\t select_commit_parent(blame->commit->id, opt_ref)) {\n+\t\t select_commit_parent(blame->commit->id, opt_ref,\n+\t\t\t\t\t blame->commit->filename)) {\n \t\t\tstring_copy(opt_file, blame->commit->filename);\n \t\t\tsetup_blame_parent_line(view, blame);\n \t\t\topen_view(view, REQ_VIEW_BLAME, OPEN_REFRESH);\n-- \n1.6.1.2.553.gdd056.dirty\n"},{"id":"103727","messageId":"20090208110628.GB14359@coredump.intra.peff.net","threadId":"17595","inReplyTo":"2c6b72b30902080255w6ccac5e9vcd961a9ab93dcdf3@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-08T11:06:28Z","receivedAt":"2009-02-08T11:06:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 08, 2009 at 11:55:55AM +0100, Jonas Fonseca wrote:\n\n> On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca wrote:\n> > One problem it does not yet handle is the\n> > cut'n'paste within the same file where the deleted line ends up in a\n> > different hunk.\n> \n> Hmm, this is trivially fixed by passing -M to git blame so maybe that\n> should just be the default for tig.\n\nYes, I think that is worth doing. It might also be nice to show the\noriginal filename in the blame output (perhaps optionally if it is\ndifferent than the original). However, you might want to look at how\n\"git gui blame\" does it. It actually shows _two_ entries for each line:\nthe origin of the content, and the commit that moved the content into\nplace.\n\nI don't know if that is worth doing in tig or not; I think you generally\nwant to assume a much more constrained screen size (though I have to\nadmit that I generally maximize my terminal to use \"tig blame\" anyway --\n80x25 just doesn't cut it).\n\n-Peff\n"},{"id":"103733","messageId":"2c6b72b30902080349m2acfe12ao2f6295187e7549d3@mail.gmail.com","threadId":"17595","inReplyTo":"20090208110042.GA14359@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T11:49:29Z","receivedAt":"2009-02-08T11:49:29Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Sun, Feb 8, 2009 at 12:00, Jeff King wrote:\n> I do have one more complaint, though. :)\n>\n> If you parent-blame far enough, you will reach a point before the file\n> existed at all, in which case blame_read_file will die() with an error.\n> It would be nice to print an error and stay on the same screen. Below is\n> a patch which implements (I think) reasonably elegant solution.\n\nOK, will apply.\n\n-- \nJonas Fonseca\n"},{"id":"103734","messageId":"2c6b72b30902080352y2ada3f36t85a05dcacb77a5bb@mail.gmail.com","threadId":"17595","inReplyTo":"20090208110628.GB14359@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-08T11:52:37Z","receivedAt":"2009-02-08T11:52:37Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Sun, Feb 8, 2009 at 12:06, Jeff King wrote:\n> On Sun, Feb 08, 2009 at 11:55:55AM +0100, Jonas Fonseca wrote:\n>\n>> On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca wrote:\n>> > One problem it does not yet handle is the\n>> > cut'n'paste within the same file where the deleted line ends up in a\n>> > different hunk.\n>>\n>> Hmm, this is trivially fixed by passing -M to git blame so maybe that\n>> should just be the default for tig.\n>\n> Yes, I think that is worth doing. It might also be nice to show the\n> original filename in the blame output (perhaps optionally if it is\n> different than the original). However, you might want to look at how\n> \"git gui blame\" does it. It actually shows _two_ entries for each line:\n> the origin of the content, and the commit that moved the content into\n> place.\n>\n> I don't know if that is worth doing in tig or not; I think you generally\n> want to assume a much more constrained screen size (though I have to\n> admit that I generally maximize my terminal to use \"tig blame\" anyway --\n> 80x25 just doesn't cut it).\n\nI wouldn't mind not showing the date and sha1 columns. The sha1 column\nis mustly there to give a clue about what lines are from the same\ncommit, but that could be done better using the ideas from git-gui.\n\nWill look into it when I get some more time ...\n\n-- \nJonas Fonseca\n"},{"id":"103912","messageId":"20090209220750.GA27232@m62s10.vlinux.de","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2009-02-09T22:07:50Z","receivedAt":"2009-02-09T22:07:50Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"First, let me say I like tig very much and apreciate your effort on\nmaking it the best console based git viewer.\n\nNow I have a little UI glitch, which might be solved already. If im\nbrowsing through a lot of commits, I'd like to have a way to advance to\ntne next/previous commit while also showing the diff like in the pictore\nbelow. Right now I alwasy press 'q' to leave the diff view, select\ncommit C and press return to show me the diff. Wouldn't it be nice to\nhave a way to advance to the next diff without leaving the diff window?\n\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n | commit A\n | >commit B\n | commit C\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n | diff --git a/tig.c b/tig.c\n | index aec50bc..2dd0ef6 100644\n | --- a/tig.c\n | +++ b/tig.c\n ....\n\nGreetings,\nPeter\n"},{"id":"103915","messageId":"20090209222236.GA4166@coredump.intra.peff.net","threadId":"17595","inReplyTo":"20090209220750.GA27232@m62s10.vlinux.de","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-02-09T22:22:36Z","receivedAt":"2009-02-09T22:22:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 09, 2009 at 11:07:50PM +0100, Peter Baumann wrote:\n\n> Now I have a little UI glitch, which might be solved already. If im\n> browsing through a lot of commits, I'd like to have a way to advance to\n> tne next/previous commit while also showing the diff like in the pictore\n> below. Right now I alwasy press 'q' to leave the diff view, select\n> commit C and press return to show me the diff. Wouldn't it be nice to\n> have a way to advance to the next diff without leaving the diff window?\n> \n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> | commit A\n> | >commit B\n> | commit C\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> | diff --git a/tig.c b/tig.c\n> | index aec50bc..2dd0ef6 100644\n> | --- a/tig.c\n> | +++ b/tig.c\n\nDon't the up and down arrows switch the commit (updating the diff pane\nas appropriate), and PgUp/PgDown scroll the diff window (I don't know\nthe actual function names, but you should be able to even rebind these\nin your tigrc if you want).\n\n-Peff\n"},{"id":"103919","messageId":"20090209223044.GB27232@m62s10.vlinux.de","threadId":"17595","inReplyTo":"20090209222236.GA4166@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2009-02-09T22:30:44Z","receivedAt":"2009-02-09T22:30:44Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:\n> On Mon, Feb 09, 2009 at 11:07:50PM +0100, Peter Baumann wrote:\n> \n> > Now I have a little UI glitch, which might be solved already. If im\n> > browsing through a lot of commits, I'd like to have a way to advance to\n> > tne next/previous commit while also showing the diff like in the pictore\n> > below. Right now I alwasy press 'q' to leave the diff view, select\n> > commit C and press return to show me the diff. Wouldn't it be nice to\n> > have a way to advance to the next diff without leaving the diff window?\n> > \n> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > | commit A\n> > | >commit B\n> > | commit C\n> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > | diff --git a/tig.c b/tig.c\n> > | index aec50bc..2dd0ef6 100644\n> > | --- a/tig.c\n> > | +++ b/tig.c\n> \n> Don't the up and down arrows switch the commit (updating the diff pane\n> as appropriate), and PgUp/PgDown scroll the diff window (I don't know\n> the actual function names, but you should be able to even rebind these\n> in your tigrc if you want).\n> \n\nDamn. I'm so used to the vi keybindings pressing j/k to move down/up\nthat I didn't check the cursor keys.\n\nSorry for the noise,\nPeter\n"},{"id":"104005","messageId":"4991814A.6050803@tedpavlic.com","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-10T13:29:46Z","receivedAt":"2009-02-10T13:29:46Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> Release notes\n> -------------\n> Incompatibilities:\n\nI notice that when I do the sequence...\n\n*) open tig\n*) hit to view first changeset\n*) hit \"j\" to scroll one line\n\nthe green highlighting on the first line moves to the second, but the \nwhitespace following the \"commit 00000000000000\" stays green. For \nexample, if I do the sequence above in the tig repo, I'm left with\n\ncommit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---\n---This line (Refs:) has GREEN BG---\n\nThe \"commit\" has a black background.\n\nIs that a bug? Or do I need to upgrade my ncurses?\n\nIf I hit a few more times (to move the screen) and then hit \"j\" \nmore (to move the highlighted line), I get this same bug randomly on \ndifferent lines.\n\nThanks --\nTed\n\nP.S.\n\nAgain, thanks for this app.\n\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104056","messageId":"2c6b72b30902101029s72628a88n16473ee30f853198@mail.gmail.com","threadId":"17595","inReplyTo":"4991814A.6050803@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-10T18:29:04Z","receivedAt":"2009-02-10T18:29:04Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Tue, Feb 10, 2009 at 14:29, Ted Pavlic wrote:\n> I notice that when I do the sequence...\n>\n> *) open tig\n> *) hit to view first changeset\n> *) hit \"j\" to scroll one line\n>\n> the green highlighting on the first line moves to the second, but the\n> whitespace following the \"commit 00000000000000\" stays green. For example,\n> if I do the sequence above in the tig repo, I'm left with\n>\n> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---\n> ---This line (Refs:) has GREEN BG---\n>\n> The \"commit\" has a black background.\n>\n> Is that a bug? Or do I need to upgrade my ncurses?\n\nSounds like a bug. Probably from the drawing optimizations in tig-0.14.\n\nNo upgrade should be necessary. Could you give me some information\nabout what terminal application you are using. Also, have you added\nany specific color settings to ~/.tigrc?\n\n> If I hit a few more times (to move the screen) and then hit \"j\" more\n> (to move the highlighted line), I get this same bug randomly on different\n> lines.\n\nThis is a good hint. Does it happen a mostly when you hit \"j\" and it\ncauses the view to be scrolled down?\n\n-- \nJonas Fonseca\n"},{"id":"104058","messageId":"2c6b72b30902101042o64a1a490ge18af497faa747c5@mail.gmail.com","threadId":"17595","inReplyTo":"20090209223044.GB27232@m62s10.vlinux.de","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-10T18:42:32Z","receivedAt":"2009-02-10T18:42:32Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Mon, Feb 9, 2009 at 23:30, Peter Baumann wrote:\n> On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:\n>> Don't the up and down arrows switch the commit (updating the diff pane\n>> as appropriate), and PgUp/PgDown scroll the diff window (I don't know\n>> the actual function names, but you should be able to even rebind these\n>> in your tigrc if you want).\n>\n> Damn. I'm so used to the vi keybindings pressing j/k to move down/up\n> that I didn't check the cursor keys.\n\nWell, initially tig worked similar to what you expected and a program\nlike slrn, where up/down (or j/k) moves between articles (commits) and\nyou have to press enter to actually show/load the commit in the diff\nview. This mode might be more natural, and Jari has argued that it\nwould make tig (and it's many forks) more bearable to on Cygwin\nrunning on an old PC.\n\nAnyway, I would like to add support for something like this in the\nfuture. But it will require some restructuring of the code to make the\nlink between the main view and it's diff view more natural.\n\n-- \nJonas Fonseca\n"},{"id":"104060","messageId":"6BA2725C-2127-48BE-871E-7449A507CCD8@silverinsanity.com","threadId":"17595","inReplyTo":"2c6b72b30902101029s72628a88n16473ee30f853198@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-10T19:07:21Z","receivedAt":"2009-02-10T19:07:21Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 10, 2009, at 1:29 PM, Jonas Fonseca wrote:\n\n> On Tue, Feb 10, 2009 at 14:29, Ted Pavlic wrote:\n>> I notice that when I do the sequence...\n>>\n>> *) open tig\n>> *) hit to view first changeset\n>> *) hit \"j\" to scroll one line\n>>\n>> the green highlighting on the first line moves to the second, but the\n>> whitespace following the \"commit 00000000000000\" stays green. For \n>> example,\n>> if I do the sequence above in the tig repo, I'm left with\n>>\n>> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---\n>> ---This line (Refs:) has GREEN BG---\n>>\n>> The \"commit\" has a black background.\n>>\n>> Is that a bug? Or do I need to upgrade my ncurses?\n>\n> Sounds like a bug. Probably from the drawing optimizations in \n> tig-0.14.\n\nI am also getting this bug. It is easiest to reproduce for me by \nrunning \"git log | tig\" and just moving the cursor down. Any action \nthat causes the entire window to update (pressing up/down at the \nbottom/top of the screen, PageUp/PageDown, or even just to \nscroll down a line) causes the line to appear normally again, although \nmovement from that point usually breaks it again.\n\n> No upgrade should be necessary. Could you give me some information\n> about what terminal application you are using. Also, have you added\n> any specific color settings to ~/.tigrc?\n\nOS 10.5.6's Terminal.app, with TERM=xterm-color\nI have no .tigrc\n\n~~ Brian\n"},{"id":"104064","messageId":"d4bc1a2a0902101129y22224c89y144b223e7d7dd463@mail.gmail.com","threadId":"17595","inReplyTo":"6BA2725C-2127-48BE-871E-7449A507CCD8@silverinsanity.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Stefan Karpinski","fromEmail":"stefan.karpinski@gmail.com","sentAt":"2009-02-10T19:29:15Z","receivedAt":"2009-02-10T19:29:15Z","isPatch":false,"sender":{"key":"stefan.karpinski@gmail.com","avatar":"https://gravatar.com/avatar/780cfb8dd7d7dc749d7276a4ca2ec24e7f0482cfce509717c5ddd165fd2cc9d9?d=mp&s=160"},"body":"On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt\n wrote:\n>\n> On Feb 10, 2009, at 1:29 PM, Jonas Fonseca wrote:\n>\n>> On Tue, Feb 10, 2009 at 14:29, Ted Pavlic wrote:\n>>>\n>>> I notice that when I do the sequence...\n>>>\n>>> *) open tig\n>>> *) hit to view first changeset\n>>> *) hit \"j\" to scroll one line\n>>>\n>>> the green highlighting on the first line moves to the second, but the\n>>> whitespace following the \"commit 00000000000000\" stays green. For example,\n>>> if I do the sequence above in the tig repo, I'm left with\n>>>\n>>> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---\n>>> ---This line (Refs:) has GREEN BG---\n>>>\n>>> The \"commit\" has a black background.\n>>>\n>>> Is that a bug? Or do I need to upgrade my ncurses?\n>>\n>> Sounds like a bug. Probably from the drawing optimizations in tig-0.14.\n>\n> I am also getting this bug. It is easiest to reproduce for me by running \"git log | tig\" and just moving the cursor down. Any action that causes the entire window to update (pressing up/down at the bottom/top of the screen, PageUp/PageDown, or even just to scroll down a line) causes the line to appear normally again, although movement from that point usually breaks it again.\n>\n>> No upgrade should be necessary. Could you give me some information\n>> about what terminal application you are using. Also, have you added\n>> any specific color settings to ~/.tigrc?\n>\n> OS 10.5.6's Terminal.app, with TERM=xterm-color\n> I have no .tigrc\n\nDitto. Same bug. Completely vanilla tig setup. OS X Leopard,\ntig-0.14-9-gd06137e, TERM=xterm-color.\n"},{"id":"104073","messageId":"2c6b72b30902101241p67a0e1e9u60c8033c4a03260c@mail.gmail.com","threadId":"17595","inReplyTo":"d4bc1a2a0902101129y22224c89y144b223e7d7dd463@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-10T20:41:21Z","receivedAt":"2009-02-10T20:41:21Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski\n wrote:\n> On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt\n> wrote:\n>>\n>> OS 10.5.6's Terminal.app, with TERM=xterm-color\n>> I have no .tigrc\n>\n> Ditto. Same bug. Completely vanilla tig setup. OS X Leopard,\n> tig-0.14-9-gd06137e, TERM=xterm-color.\n\nLooks like there might be a pattern and I might have an excuse to go\nknock on the door of one of my \"Mac\" friends. ;) However, first I\nwould kindly ask if one of you have time to test the attached patch.\n\nThanks both of you and sorry for the inconvenience.\n\n-- \nJonas Fonseca\n\n\nFrom 3670b9f20c49c46c6418d7dbcce8265b2fe8a853 Mon Sep 17 00:00:00 2001\nFrom: Jonas Fonseca \nDate: Tue, 10 Feb 2009 21:33:18 +0100\nSubject: [PATCH] Fix regression where a line was not cleared when not selected anymore\n\nIntroduced in 273c28df2aa5cc0d122b1a0f3c0014a56ab8c392 (Tree view: make\ndrawing more smooth by using the dirty flag).\n---\n tig.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/tig.c b/tig.c\nindex 7072094..02f4bd8 100644\n--- a/tig.c\n+++ b/tig.c\n@@ -2055,7 +2055,7 @@ draw_view_line(struct view *view, unsigned int lineno)\n \tline = &view->line[view->offset + lineno];\n \n \twmove(view->win, lineno, 0);\n-\tif (line->cleareol)\n+\tif (line->cleareol || (line->selected && !selected))\n \t\twclrtoeol(view->win);\n \tview->col = 0;\n \tview->curline = line;\n-- \n1.6.1.1.347.g3f81d\n\n"},{"id":"104075","messageId":"3902F3BD-6EE5-4896-9E96-C4A1C4B6E9AF@silverinsanity.com","threadId":"17595","inReplyTo":"2c6b72b30902101241p67a0e1e9u60c8033c4a03260c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-10T20:49:54Z","receivedAt":"2009-02-10T20:49:54Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 10, 2009, at 3:41 PM, Jonas Fonseca wrote:\n\n> On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski\n> wrote:\n>> On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt\n>> wrote:\n>>>\n>>> OS 10.5.6's Terminal.app, with TERM=xterm-color\n>>> I have no .tigrc\n>>\n>> Ditto. Same bug. Completely vanilla tig setup. OS X Leopard,\n>> tig-0.14-9-gd06137e, TERM=xterm-color.\n>\n> Looks like there might be a pattern and I might have an excuse to go\n> knock on the door of one of my \"Mac\" friends. ;) However, first I\n> would kindly ask if one of you have time to test the attached patch.\n\nThat fixes half the problem. It no longer leaves a highlight on the \nwrong line, but the newly selected line does not highlight the empty \nspace at the end of the line.\n"},{"id":"104077","messageId":"2c6b72b30902101313r5dcea490s3bc72d404a98997f@mail.gmail.com","threadId":"17595","inReplyTo":"3902F3BD-6EE5-4896-9E96-C4A1C4B6E9AF@silverinsanity.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-10T21:13:49Z","receivedAt":"2009-02-10T21:13:49Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt wrote:\n> That fixes half the problem. It no longer leaves a highlight on the wrong\n> line, but the newly selected line does not highlight the empty space at the\n> end of the line.\n\nI believe the empty space is the cursor, but I am not sure. At least\ntig-0.14 should be more consistent regarding the cursor position,\nwhich is now always placed at the end of the selected line, except\nwhen the input prompt is in use.\n\n-- \nJonas Fonseca\n"},{"id":"104079","messageId":"F48CDFE6-4402-49F5-8716-B8D9C40DD201@silverinsanity.com","threadId":"17595","inReplyTo":"2c6b72b30902101313r5dcea490s3bc72d404a98997f@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-02-10T21:18:00Z","receivedAt":"2009-02-10T21:18:00Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 10, 2009, at 4:13 PM, Jonas Fonseca wrote:\n\n> On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt > wrote:\n>> That fixes half the problem. It no longer leaves a highlight on \n>> the wrong\n>> line, but the newly selected line does not highlight the empty \n>> space at the\n>> end of the line.\n>\n> I believe the empty space is the cursor, but I am not sure. At least\n> tig-0.14 should be more consistent regarding the cursor position,\n> which is now always placed at the end of the selected line, except\n> when the input prompt is in use.\n\nThat's not what I'm referring to. I mean that if there's a line that \ndoes not take the entire width of the screen, the space from the end \nof the text to the end of the screen is black.\n"},{"id":"104083","messageId":"878woet28x.fsf@jondo.cante.net","threadId":"17595","inReplyTo":"2c6b72b30902101042o64a1a490ge18af497faa747c5@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2009-02-10T21:23:42Z","receivedAt":"2009-02-10T21:23:42Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Jonas Fonseca writes:\n\n> On Mon, Feb 9, 2009 at 23:30, Peter Baumann wrote:\n>\n>> On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:\n>>> Don't the up and down arrows switch the commit (updating the diff pane\n>>> as appropriate), and PgUp/PgDown scroll the diff window (I don't know\n>>> the actual function names, but you should be able to even rebind these\n>>> in your tigrc if you want).\n>>\n>> Damn. I'm so used to the vi keybindings pressing j/k to move down/up\n>> that I didn't check the cursor keys.\n>\n> Well, initially tig worked similar to what you expected and a program\n> like slrn, where up/down (or j/k) moves between articles (commits) and\n> you have to press enter to actually show/load the commit in the diff\n> view. This mode might be more natural, and Jari has argued that it\n> would make tig (and it's many forks) more bearable to on Cygwin\n> running on an old PC.\n\nIt also helps when you want to see only particular commit; you scroll to\ncorrect location as ask display by pressing RET. If aut-update is in\neffect, the other commits in between tie up the cursor movement,\nespecially if the history is long: tap, tap, tap .... and you'd have to\nwait for all all screen to update line by line.\n\nIdea: The auto-update feature could be even turned on/off with a\ncommand-key . But an comand line option would do for me, as long as the\nbehaviot is configurable. It is slow under Cygwin, especially on\nnetworked case, where Cygwin resides on remote disk, not the local one.\n\nJari\n"},{"id":"104184","messageId":"4992DA9E.4040107@tedpavlic.com","threadId":"17595","inReplyTo":"2c6b72b30902101029s72628a88n16473ee30f853198@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-11T14:03:10Z","receivedAt":"2009-02-11T14:03:10Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> No upgrade should be necessary. Could you give me some information\n> about what terminal application you are using. Also, have you added\n> any specific color settings to ~/.tigrc?\n\nOS X 10.4.11\niTerm 0.9.6.1201\nTERM=xterm-color\n\nI have no ~/.tigrc\n\n>> If I hit a few more times (to move the screen) and then hit \"j\" more\n>> (to move the highlighted line), I get this same bug randomly on different\n>> lines.\n>\n> This is a good hint. Does it happen a mostly when you hit \"j\" and it\n> causes the view to be scrolled down?\n\nThe problem only occurs with \"j\" and \"k\" when viewing multi-line \ndisplays. I do /not/ see the problem when viewing the one-line changeset \nhistory. It only causes a problem when I view the multi-line displays \n(e.g., when actually viewing a changeset).\n\nFor example, in git.git, if I \"tig\" and then scroll through the \nchangesets, I don't see the problem. If I on a changeset so that it \nopens in the bottom half of the screen, I see the problem when I start \n\"j\" and \"k\"'ing there.\n\nThanks --\nTed\n\n\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104185","messageId":"4992DB72.4080109@tedpavlic.com","threadId":"17595","inReplyTo":"3902F3BD-6EE5-4896-9E96-C4A1C4B6E9AF@silverinsanity.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-11T14:06:42Z","receivedAt":"2009-02-11T14:06:42Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> That fixes half the problem. It no longer leaves a highlight on the\n> wrong line, but the newly selected line does not highlight the empty\n> space at the end of the line.\n\nI haven't tried the patch yet, but I can tell you that (on my system) \nthe other \"half\" of the problem is there before the patch.\n\nThat is, the trailing whitespace on a new line goes without highlight. I \nwas under the (wrong?) impression that this was desired and that the \nwhitespace highlighting was a bug. No?\n\n(in fact, it might be useful if the trailing \"screen space\" is *not* \nhighlighted. That makes it easy to X-ray trailing whitespace buried in \nthe changeset)\n\n--Ted\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104187","messageId":"4992DCE1.60008@tedpavlic.com","threadId":"17595","inReplyTo":"4992DA9E.4040107@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-11T14:12:49Z","receivedAt":"2009-02-11T14:12:49Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":">> No upgrade should be necessary. Could you give me some information\n>> about what terminal application you are using. Also, have you added\n>> any specific color settings to ~/.tigrc?\n>\n> OS X 10.4.11\n> iTerm 0.9.6.1201\n> TERM=xterm-color\n>\n> I have no ~/.tigrc\n\nPerhaps not surprisingly, when I ssh into a Linux machine and run tig, I \nhave the same problem.\n\nThat is, \"tig\" is being run on the Linux machine, but the terminal is on \nmy Mac.\n\nIt might be interesting that although several people with this problem \nuse a Mac, we do not use the same terminal program.\n\n--Ted\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104188","messageId":"4992DE83.6080803@tedpavlic.com","threadId":"17595","inReplyTo":"2c6b72b30902101241p67a0e1e9u60c8033c4a03260c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-11T14:19:47Z","receivedAt":"2009-02-11T14:19:47Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> Looks like there might be a pattern and I might have an excuse to go\n> knock on the door of one of my \"Mac\" friends. ;) However, first I\n> would kindly ask if one of you have time to test the attached patch.\n\nIt fixes it for me.\n\nAs noted, the highlight in the changesets does not go to the end of the \nline (where there is a cursor displayed) as it did before. I can see how \nsome people might view this as a feature (i.e., having the whole line \nhighlighted).\n\n--Ted\n\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104200","messageId":"slrngp5tqk.u46.sitaramc@sitaramc.homelinux.net","threadId":"17595","inReplyTo":"2c6b72b30902080207m4a1e14b7j4862f9a8b7ca32a9@mail.gmail.com","subject":"showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-11T16:05:40Z","receivedAt":"2009-02-11T16:05:40Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-08, Jonas Fonseca wrote:\n> On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty wrote:\n\n>> But I must say that the last time I did this, the hunks that\n>> tig showed me were more granular than what 'git gui' did; no\n>> idea why. To do what I wanted to do in 'git gui' was\n>> possible, by staging line by line instead of hunk by hunk,\n>> but I didn't fancy all that clicking and tig saved me.\n\n> Great to hear. I sometimes, miss though, being able to lower the diff\n> context to 1 or 2, however, maybe I should learn to commit more often\n> instead.\n\nIs there any way to see the sha1 of the parent commit in any\nof the displays, like gitk does?\n\nI know you're only parsing the 4 or 5 basic git commands,\nand none of those do, so I guess I know the answer :-( but\nit doesn't hurt to ask.\n"},{"id":"104224","messageId":"49930F1A.6030509@tedpavlic.com","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-11T17:47:06Z","receivedAt":"2009-02-11T17:47:06Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> What is tig?\n\n\n*) Is there any way for \"tig\" to emulate \"less -R\"?\n\nThat is, if an output is already colorized, can tig just pass through \nthe ANSI?\n\n\n*) When doing \"git diff|tig\" when there directory is clean, tig should \nprobably exit immediately, right?\n\n\n*) Also, is there a way to configure \"tig\" to colorize and *exit* if the \npiped text doesn't fill a page?\n\n\n(in other words, I'd like \"tig\" to be able to replace my current \"less \n-FRX\" pager)\n\nThanks --\nTed\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"104320","messageId":"2c6b72b30902111708t4513aa18wca9b7306796509ce@mail.gmail.com","threadId":"17595","inReplyTo":"49930F1A.6030509@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-12T01:08:14Z","receivedAt":"2009-02-12T01:08:14Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Wed, Feb 11, 2009 at 18:47, Ted Pavlic wrote:\n> *) Is there any way for \"tig\" to emulate \"less -R\"?\n>\n> That is, if an output is already colorized, can tig just pass through the\n> ANSI?\n\nTig is heavily tied to ncurses and as far as I know ncurses does not\nsupport this. So it would require tig to parse the ANSI terminal codes\ninto some representation from which the equivalent calls to the\nncurses API is made.\n\n> *) When doing \"git diff|tig\" when there directory is clean, tig should\n> probably exit immediately, right?\n\nYes, good idea. The blame and main view currently does this too. Will\nlook into it.\n\n> *) Also, is there a way to configure \"tig\" to colorize and *exit* if the\n> piped text doesn't fill a page?\n\nNo. However, this I have actually considered to support at some point,\nsince it would make it possible to test the rendering. Again, this is\nnot something ncurses supports as far as I know, so would require some\nkind ofl \"ANSI\" code emitter.\n\n> (in other words, I'd like \"tig\" to be able to replace my current \"less -FRX\"\n> pager)\n\nIt will probably take a some time to get there, but I am open to\nmoving in this direction.\n\n-- \nJonas Fonseca\n"},{"id":"104321","messageId":"2c6b72b30902111719r6fd25dc7uc22b471f7904bedc@mail.gmail.com","threadId":"17595","inReplyTo":"slrngp5tqk.u46.sitaramc@sitaramc.homelinux.net","subject":"Re: showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-12T01:19:17Z","receivedAt":"2009-02-12T01:19:17Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty wrote:\n> Is there any way to see the sha1 of the parent commit in any\n> of the displays, like gitk does?\n>\n> I know you're only parsing the 4 or 5 basic git commands,\n> and none of those do, so I guess I know the answer :-( but\n> it doesn't hurt to ask.\n\nIt is sort of possible by setting the TIG_DIFF_CMD environment\nvariable to something appropriate, for example using (and I don't know\nif this will be formatted correctly):\n\nexport TIG_DIFF_CMD='git show -p --stat -C -M\n--pretty=format:commit%x20%H%d%nAuthor:%x20%an%x20<%ae>%x20%ai%nParent:%x20%P%nSubject:%x20%s%n%n%b\n%(commit)'\n\nYou need to avoid using space except for where it really separates\narguments, which is why the obscure %x20 is used. ;)\n\nAnother solution would be to create a script, which just expects the\ncommit SHA1 as its first argument and then do the formatting there and\nthen use:\n\nexport TIG_DIFF_CMD=\"/my/script %(commit)\"\n\n-- \nJonas Fonseca\n"},{"id":"104322","messageId":"2c6b72b30902111730u3b38dd5fpc0b3a8da695de219@mail.gmail.com","threadId":"17595","inReplyTo":"4992DB72.4080109@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-12T01:30:02Z","receivedAt":"2009-02-12T01:30:02Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Wed, Feb 11, 2009 at 15:06, Ted Pavlic wrote:\n> That is, the trailing whitespace on a new line goes without highlight. I was\n> under the (wrong?) impression that this was desired and that the whitespace\n> highlighting was a bug. No?\n\nThe basic idea of the \"cursor line\" is that the whole line including\nany trailing space is highlighted.\n\n> (in fact, it might be useful if the trailing \"screen space\" is *not*\n> highlighted. That makes it easy to X-ray trailing whitespace buried in the\n> changeset)\n\nWell, I don't know if tig is the right tool for detecting that.\n\nI have noted your comment about different terminals being in play. A\nfact that is rather discouraging. Will try to get some time in front\nof OSX to look more into it. I have an idea for a temporary fix, which\nI would like you to test when it is ready.\n\n-- \nJonas Fonseca\n"},{"id":"104337","messageId":"slrngp75r8.q57.sitaramc@sitaramc.homelinux.net","threadId":"17595","inReplyTo":"2c6b72b30902111719r6fd25dc7uc22b471f7904bedc@mail.gmail.com","subject":"Re: showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-12T03:28:40Z","receivedAt":"2009-02-12T03:28:40Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-12, Jonas Fonseca wrote:\n> On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty wrote:\n>> Is there any way to see the sha1 of the parent commit in any\n>> of the displays, like gitk does?\n>>\n>> I know you're only parsing the 4 or 5 basic git commands,\n>> and none of those do, so I guess I know the answer :-( but\n>> it doesn't hurt to ask.\n>\n> It is sort of possible by setting the TIG_DIFF_CMD environment\n> variable to something appropriate, for example using (and I don't know\n> if this will be formatted correctly):\n>\n> export TIG_DIFF_CMD='git show -p --stat -C -M\n> --pretty=format:commit%x20%H%d%nAuthor:%x20%an%x20<%ae>%x20%ai%nParent:%x20%P%nSubject:%x20%s%n%n%b\n> %(commit)'\n>\n> You need to avoid using space except for where it really separates\n> arguments, which is why the obscure %x20 is used. ;)\n>\n> Another solution would be to create a script, which just expects the\n> commit SHA1 as its first argument and then do the formatting there and\n> then use:\n>\n> export TIG_DIFF_CMD=\"/my/script %(commit)\"\n\nOK thanks -- I'll give that a shot when I get a chance.\n\nRegards,\n\nSitaram\n"},{"id":"104434","messageId":"op.uo9di902a8ed4e@dellschleppa","threadId":"17595","inReplyTo":"20090205204436.GA6072@diku.dk","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-12T21:48:35Z","receivedAt":"2009-02-12T21:48:35Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Thu, 05 Feb 2009 21:44:36 +0100, Jonas Fonseca wrote:\n\n> Here is a much needed update fixing multiple regressions from the\n> introduction of the IO API in 0.13.\n\nThank you for this _really_ nice program.\n\nOne thing came to my mind. When I use 'S' and then 'u' to stage/unstage \nfiles, it would be nice if I could press a key(maybe 'C') to fire up my \n$EDITOR, enter my commit message, let tig do the commit and find myself \nback into the updated status view. Does this sound reasonable?\n\nViele Grüße,\n\n Tilo\n"},{"id":"104441","messageId":"2c6b72b30902121424o5d4ac0d7u67a7afb3b861aa19@mail.gmail.com","threadId":"17595","inReplyTo":"op.uo9di902a8ed4e@dellschleppa","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-12T22:24:56Z","receivedAt":"2009-02-12T22:24:56Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz wrote:\n> One thing came to my mind. When I use 'S' and then 'u' to stage/unstage\n> files, it would be nice if I could press a key(maybe 'C') to fire up my\n> $EDITOR, enter my commit message, let tig do the commit and find myself back\n> into the updated status view. Does this sound reasonable?\n\nSure, you can achieve this very easily. For example, I have the\nfollowing bindings in my ~/.tigrc:\n\n bind generic + !git commit --amend\n bind generic . !git commit\n\nWith tig-0.14, you can also put bindings in your ~/.gitconfig or the\nproject specific .git/config file using:\n\n [tig \"bind\"]\n generic = C !git commit\n generic = w !firefox http://repo.or.cz/w/tig.git?h=%(commit)\n\nThe last one uses \"browsing state variables\". There is more\ninformation about those in tigrc(5)[1]\n\n[1] http://jonas.nitro.dk/tig/tigrc.5.html#_actions\n\n-- \nJonas Fonseca\n"},{"id":"104446","messageId":"op.uo9hiqqqa8ed4e@dellschleppa","threadId":"17595","inReplyTo":"2c6b72b30902121424o5d4ac0d7u67a7afb3b861aa19@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-12T23:14:40Z","receivedAt":"2009-02-12T23:14:40Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Thu, 12 Feb 2009 23:24:56 +0100, Jonas Fonseca \n wrote:\n\n> On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz wrote:\n>> One thing came to my mind. When I use 'S' and then 'u' to stage/unstage\n>> files, it would be nice if I could press a key(maybe 'C') to fire up my\n>> $EDITOR, enter my commit message, let tig do the commit and find myself \n>> back\n>> into the updated status view. Does this sound reasonable?\n>\n> Sure, you can achieve this very easily. For example, I have the\n> following bindings in my ~/.tigrc:\n>\n> bind generic + !git commit --amend\n> bind generic . !git commit\n>\n> With tig-0.14, you can also put bindings in your ~/.gitconfig or the\n> project specific .git/config file using:\n>\n> [tig \"bind\"]\n> generic = C !git commit\n> generic = w !firefox http://repo.or.cz/w/tig.git?h=%(commit)\n>\n> The last one uses \"browsing state variables\". There is more\n> information about those in tigrc(5)[1]\n\nWow, that flexibility is really impressive!\n\nThen I have another question: Did you ever thought of a branch view, where \nyou can see, create, delete and merge the different branches which are in \na git project.\n\nBest regards,\n(oops, I forgot to change this to the lists language in my previous post)\n\n Tilo\n"},{"id":"104470","messageId":"20090213023120.GA7322@b2j","threadId":"17595","inReplyTo":"2c6b72b30902121424o5d4ac0d7u67a7afb3b861aa19@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-02-13T02:31:20Z","receivedAt":"2009-02-13T02:31:20Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"On Thu, 12 Feb 2009, Jonas Fonseca wrote:\n> The last one uses \"browsing state variables\". There is more\n> information about those in tigrc(5)[1]\n\nI can see that scroll-left/right only do it for one column, that is\nnot very convenient, Will it be possible to scroll for 10 columns or\nhalf screen?\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n唐詩260 李益 江南曲\n 嫁得瞿塘賈 朝朝誤妾期 早知潮有信 嫁與弄潮兒\n"},{"id":"104556","messageId":"2c6b72b30902131557w1bfe9e43l34b28a22d202e881@mail.gmail.com","threadId":"17595","inReplyTo":"20090213023120.GA7322@b2j","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-13T23:57:02Z","receivedAt":"2009-02-13T23:57:02Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Fri, Feb 13, 2009 at 03:31, bill lam wrote:\n> I can see that scroll-left/right only do it for one column, that is\n> not very convenient, Will it be possible to scroll for 10 columns or\n> half screen?\n\nCertainly, the one column thing was good for testing but agreeable not\nvery usable so I have made the behavior of horizontal scrolling\nconfigurable. You can either set the 'horizontal-scroll' variable to\nthe number of columns or the percentage of the view width you want to\nscroll. Defaults to scrolling 50% of the view width.\n\n-- \nJonas Fonseca\n"},{"id":"104580","messageId":"20090214033139.GA7563@b2j","threadId":"17595","inReplyTo":"2c6b72b30902131557w1bfe9e43l34b28a22d202e881@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-02-14T03:31:39Z","receivedAt":"2009-02-14T03:31:39Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"On Sat, 14 Feb 2009, Jonas Fonseca wrote:\n> Certainly, the one column thing was good for testing but agreeable not\n> very usable so I have made the behavior of horizontal scrolling\n> configurable. You can either set the 'horizontal-scroll' variable to\n> the number of columns or the percentage of the view width you want to\n> scroll. Defaults to scrolling 50% of the view width.\n\nThanks. I tested and found that there might be a bug. For some lines\n(>100 columns) it stoped scrolling even there are text there, instead\nit displayed a ~ sign at the edge. Even I set in the .tigrc\n\nset horizontal-scroll = 1\n\nIt still did not works.\n\nAlso, when editing in the command mode, the back-space and left arrow\nkeys do not move cursor. It can only use ctrl-h to delete the last\ncharacter. Apparently it did not use readline and was impossible to\nrecall history using up-arrow key. It should be perfect if it use\nreadline and can also work in vi keybinding mode.\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n唐詩209 李商隱 錦瑟\n 錦瑟無端五十絃 一絃一柱思華年 莊生曉夢迷蝴蝶 望帝春心託杜鵑\n 滄海月明珠有淚 藍田日暖玉生煙 此情可待成追憶 只是當時已惘然\n"},{"id":"104851","messageId":"2c6b72b30902151522l5abcb2c6rdf0a43630fb97f5f@mail.gmail.com","threadId":"17595","inReplyTo":"20090214033139.GA7563@b2j","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-15T23:22:11Z","receivedAt":"2009-02-15T23:22:11Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"2009/2/14 bill lam :\n> On Sat, 14 Feb 2009, Jonas Fonseca wrote:\n>> [About horizontal scrolling]\n>\n> Thanks. I tested and found that there might be a bug. For some lines\n> (>100 columns) it stoped scrolling even there are text there, instead\n> it displayed a ~ sign at the edge.\n\nThis should have been addressed in tig-0.14.1.\n\n> Also, when editing in the command mode, the back-space and left arrow\n> keys do not move cursor. It can only use ctrl-h to delete the last\n> character. Apparently it did not use readline and was impossible to\n> recall history using up-arrow key. It should be perfect if it use\n> readline and can also work in vi keybinding mode.\n\nAccording to the ncurses FAQ, it is not straight forward to use\nreadline. Of course you could call out, but then views loading in the\nbackground would stop working. I know this part of tig hasn't received\na lot of work, and it has been noted in the TODO. I would be happy to\ngive you some pointers if you are interested in looking into this\nyourself.\n\n-- \nJonas Fonseca\n"},{"id":"104859","messageId":"2c6b72b30902151547q5bf183f2q1e846f261825671c@mail.gmail.com","threadId":"17595","inReplyTo":"op.uo9hiqqqa8ed4e@dellschleppa","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-15T23:47:05Z","receivedAt":"2009-02-15T23:47:05Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz wrote:\n> Then I have another question: Did you ever thought of a branch view, where\n> you can see, create, delete and merge the different branches which are in a\n> git project.\n\nI have thought about it. The question is if a separate view is\nnecessary or if the main view would do. For example, I sometimes use\ngitk when I need to rename branches or prepare for rebasing a\npatchset. One idea I would like to explore is to provide a compressed\nversion of the main view, where \"intermediate\" commits are hidden,\nthis way you could easily get a view of the relationship between\nbranches.\n\nThe simplest thing to make it easier to experiment with new features\nwould probably be to introduce a new external command specifier:\n%(prompt:), possibly with some regex for validation. Then you\ncould add in your ~/.tigrc:\n\nbind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)\n\n-- \nJonas Fonseca\n"},{"id":"104876","messageId":"slrngphgk1.hul.sitaramc@sitaramc.homelinux.net","threadId":"17595","inReplyTo":"2c6b72b30902151547q5bf183f2q1e846f261825671c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-16T01:33:53Z","receivedAt":"2009-02-16T01:33:53Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-15, Jonas Fonseca wrote:\n> patchset. One idea I would like to explore is to provide a compressed\n> version of the main view, where \"intermediate\" commits are hidden,\n> this way you could easily get a view of the relationship between\n> branches.\n\nlike 'gitk --simplify-by-decoration --all'?\n"},{"id":"104939","messageId":"2c6b72b30902160410g25e80514q318b65ea4614cdc1@mail.gmail.com","threadId":"17595","inReplyTo":"slrngphgk1.hul.sitaramc@sitaramc.homelinux.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-16T12:10:16Z","receivedAt":"2009-02-16T12:10:16Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty wrote:\n> On 2009-02-15, Jonas Fonseca wrote:\n>> patchset. One idea I would like to explore is to provide a compressed\n>> version of the main view, where \"intermediate\" commits are hidden,\n>> this way you could easily get a view of the relationship between\n>> branches.\n>\n> like 'gitk --simplify-by-decoration --all'?\n\nGreat, didn't know about this option. If only tig could show the\nrevision graph properly ... ;)\n\n-- \nJonas Fonseca\n"},{"id":"104954","messageId":"slrngpj0md.e6h.sitaramc@sitaramc.homelinux.net","threadId":"17595","inReplyTo":"2c6b72b30902160410g25e80514q318b65ea4614cdc1@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-02-16T15:14:21Z","receivedAt":"2009-02-16T15:14:21Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-02-16, Jonas Fonseca wrote:\n> On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty wrote:\n>> On 2009-02-15, Jonas Fonseca wrote:\n>>> patchset. One idea I would like to explore is to provide a compressed\n>>> version of the main view, where \"intermediate\" commits are hidden,\n>>> this way you could easily get a view of the relationship between\n>>> branches.\n>>\n>> like 'gitk --simplify-by-decoration --all'?\n>\n> Great, didn't know about this option. If only tig could show the\n\n'git log' acquired it recently, or more precisely git\nrev-list did, I think.\n\n> revision graph properly ... ;)\n\nYes I was going to ask about that, having been confused by\nthe graph once in a while. You may want to consider using a\nfew other characters than the 4 you currently do (if indeed\nthat is the problem).\n\nI'm interested in this too, and I do sometimes have complex\nbranch relationships in my work. I'm no longer much of a C\nprogrammer but I can certainly help test.\n"},{"id":"104955","messageId":"18071eea0902160725n2e918883wbc9bfc57be0b7d45@mail.gmail.com","threadId":"17595","inReplyTo":"slrngpj0md.e6h.sitaramc@sitaramc.homelinux.net","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Thomas Adam","fromEmail":"thomas.adam22@gmail.com","sentAt":"2009-02-16T15:25:23Z","receivedAt":"2009-02-16T15:25:23Z","isPatch":false,"sender":{"key":"thomas.adam22@gmail.com","avatar":"https://gravatar.com/avatar/137f9858bc6bfd5b2f743aefd988c81ce0cbd306248889df80e269519cfc8741?d=mp&s=160"},"body":"2009/2/16 Sitaram Chamarty :\n> Yes I was going to ask about that, having been confused by\n> the graph once in a while. You may want to consider using a\n> few other characters than the 4 you currently do (if indeed\n> that is the problem).\n>\n> I'm interested in this too, and I do sometimes have complex\n> branch relationships in my work. I'm no longer much of a C\n> programmer but I can certainly help test.\n\nI started work on this last year, but it got pushed further and\nfurther down my todo list. Basically, there's extended characters\ndefined as part of ncurses for just this sort of \"drawing\" operation.\n\n-- Thomas Adam\n"},{"id":"104996","messageId":"2c6b72b30902161152q3de61b9brad746b25bfcea025@mail.gmail.com","threadId":"17595","inReplyTo":"18071eea0902160725n2e918883wbc9bfc57be0b7d45@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-16T19:52:19Z","receivedAt":"2009-02-16T19:52:19Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Mon, Feb 16, 2009 at 16:25, Thomas Adam wrote:\n> 2009/2/16 Sitaram Chamarty :\n>> Yes I was going to ask about that, having been confused by\n>> the graph once in a while. You may want to consider using a\n>> few other characters than the 4 you currently do (if indeed\n>> that is the problem).\n>\n> I started work on this last year, but it got pushed further and\n> further down my todo list. Basically, there's extended characters\n> defined as part of ncurses for just this sort of \"drawing\" operation.\n\nYes, I think we need to go for something squarish like qgit and giggle.\n\nWith this rewrite I it could also be nice to allow the graph rendering\nto be more incremental by changing the commit struct to point to the\nparent commits. This will also enable support for moving the cursor to\nthe parent commit in the main view and calculate information like the\nFollows/Preceeds in gitk.\n\n-- \nJonas Fonseca\n"},{"id":"105007","messageId":"op.upgqjej6a8ed4e@dellschleppa","threadId":"17595","inReplyTo":"2c6b72b30902151547q5bf183f2q1e846f261825671c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-16T21:12:40Z","receivedAt":"2009-02-16T21:12:40Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca \n wrote:\n\n> On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz wrote:\n>> Then I have another question: Did you ever thought of a branch view, \n>> where\n>> you can see, create, delete and merge the different branches which are \n>> in a\n>> git project.\n>\n> I have thought about it. The question is if a separate view is\n> necessary or if the main view would do. For example, I sometimes use\n> gitk when I need to rename branches or prepare for rebasing a\n> patchset. One idea I would like to explore is to provide a compressed\n> version of the main view, where \"intermediate\" commits are hidden,\n> this way you could easily get a view of the relationship between\n> branches.\n\nI'm not sure if I understood it correctly. Do you mean, only commits are \nshown, which are heads of some branch? If so, what if more than one head \npoints to the same commit?\n\nThe branch thing came into my mind, because it's the only thing which \nkeeps me from using tig exclusively. I sometimes switch to git-gui to do \nthe branch handling. Since I really like those \"one key press is one \ncommand\" kind of programs like tig (or mc, aptitude, mocp, ...), it would \nbe really nice to have the branches in tig too. The nice thing of programs \nlike tig is (matter of taste of course), that once you get used to the \nkeys, you don't have to think about commands anymore, you just do them.\n\nI think I would prefer a branch view, because then one could also have a \nbranch-view keymap with specialized commands. One possibility would be \n(just as example):\n\nThe view shows something like this (here an example from the tig git \nrepository)\n\n master\n* my_feature_bar\nX my_feature_foo\n origin/HEAD\n origin/master\n origin/release\n\nThe current branch is marked by '*'. Now let's assume, I am with my cursor \non the line with the 'X', I could think of the keys\n\nd (d)elete the X-marked branch, given is has already been merged into \nanother branch\nn create a (n)ew branch, based on the X-marked branch,\n ask for the new name and (maybe checkout the new branch)\nc (c)heckout the branch\nr (r)ename the branch\nR (r)eset branch\n...\n\nI don't think it's necessary to reproduce all the nice options git-gui \nhas, but if there would be a branch view with the most used 5 commands / \nwork steps, it would cover 95% of the daily \"branch work\" which is needed. \nAnd it would be simply awesome, if we could do this without leaving tig, \nbut instead use this very nice and fast \"one key, one command\" also for \nthe branches. Of course the more complicated and special cases can be \nalways handled by tig by pressing ':' and entering a git command.\n\n> The simplest thing to make it easier to experiment with new features\n> would probably be to introduce a new external command specifier:\n> %(prompt:), possibly with some regex for validation. Then you\n> could add in your ~/.tigrc:\n>\n> bind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)\n\nAhh, ok, so tig would issue a prompt and ask me for the name?\n\n\nThanks for the great program!\n\n\nBTW, is the git list the right list to discuss bugs / patches for tig?\n\nBest regards,\n\n Tilo\n"},{"id":"105018","messageId":"op.upgsjljja8ed4e@dellschleppa","threadId":"17595","inReplyTo":"2c6b72b30902151547q5bf183f2q1e846f261825671c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-16T21:55:59Z","receivedAt":"2009-02-16T21:55:59Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca \n wrote:\n\n> I have thought about it. The question is if a separate view is\n> necessary or if the main view would do. For example, I sometimes use\n> gitk when I need to rename branches or prepare for rebasing a\n> patchset. One idea I would like to explore is to provide a compressed\n> version of the main view, where \"intermediate\" commits are hidden,\n> this way you could easily get a view of the relationship between\n> branches.\n\nAfter seeing\n\n./gitk --simplify-by-decoration --all\n\nfor the first time today I think now I know better what you mean. \nNevertheless, compared to a separate branch-view, there are two points:\n- How to I select a branch, if there is more than one branch on one commit \n(and thus on one line)\n- Would it still be possible to create nice and fast one (or two) key \ncommands for the most used every-day branch commands.\n\nBest regards,\n\n Tilo\n"},{"id":"105089","messageId":"e5bfff550902162347m4260f1bev51c1e990df4577@mail.gmail.com","threadId":"17595","inReplyTo":"2c6b72b30902161152q3de61b9brad746b25bfcea025@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2009-02-17T07:47:49Z","receivedAt":"2009-02-17T07:47:49Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Mon, Feb 16, 2009 at 20:52, Jonas Fonseca wrote:\n>\n> Yes, I think we need to go for something squarish like qgit and giggle.\n>\n\nThanks to an anonymous contributor graphs in qgit are no squarish anymore !!!\n\nPull or download from qgit public repo to enjoy the qgit graph cool\nnew look! :-)\n\ngit://git.kernel.org/pub/scm/qgit/qgit4.git\n"},{"id":"105635","messageId":"499EE761.2010902@tedpavlic.com","threadId":"17595","inReplyTo":"2c6b72b30902101241p67a0e1e9u60c8033c4a03260c@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-20T17:24:49Z","receivedAt":"2009-02-20T17:24:49Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"> Looks like there might be a pattern and I might have an excuse to go\n> knock on the door of one of my \"Mac\" friends. ;) However, first I\n> would kindly ask if one of you have time to test the attached patch.\n\nAny verdict on this patch (it WFM)? I notice tig is still unpatched to \nfix this problem.\n\nThanks --\nTed\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"105639","messageId":"2c6b72b30902201034r47850c8aq248b673ee96bdf3a@mail.gmail.com","threadId":"17595","inReplyTo":"499EE761.2010902@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-20T18:34:39Z","receivedAt":"2009-02-20T18:34:39Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Fri, Feb 20, 2009 at 18:24, Ted Pavlic wrote:\n>> Looks like there might be a pattern and I might have an excuse to go\n>> knock on the door of one of my \"Mac\" friends. ;) However, first I\n>> would kindly ask if one of you have time to test the attached patch.\n>\n> Any verdict on this patch (it WFM)? I notice tig is still unpatched to fix\n> this problem.\n\nI didn't look more into it. Maybe you can try the attached patch for me.\n\n-- \nJonas Fonseca\n\n\nFrom 270e894b59cac1baa3ee2cb4c12f320efb3fea30 Mon Sep 17 00:00:00 2001\nFrom: Jonas Fonseca \nDate: Tue, 10 Feb 2009 21:33:18 +0100\nSubject: [PATCH] Fix regression where a line was not cleared when not selected anymore\n\nIntroduced in 273c28df2aa5cc0d122b1a0f3c0014a56ab8c392 (Tree view: make\ndrawing more smooth by using the dirty flag).\n---\n tig.c | 9 +++++++--\n 1 files changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/tig.c b/tig.c\nindex 2a3ab3a..fbbd1cc 100644\n--- a/tig.c\n+++ b/tig.c\n@@ -2073,6 +2073,7 @@ draw_view_line(struct view *view, unsigned int lineno)\n {\n \tstruct line *line;\n \tbool selected = (view->offset + lineno == view->lineno);\n+\tbool cleareol;\n \n \tassert(view_is_displayed(view));\n \n@@ -2080,10 +2081,9 @@ draw_view_line(struct view *view, unsigned int lineno)\n \t\treturn FALSE;\n \n \tline = &view->line[view->offset + lineno];\n+\tcleareol = line->cleareol || (line->selected && !selected);\n \n \twmove(view->win, lineno, 0);\n-\tif (line->cleareol)\n-\t\twclrtoeol(view->win);\n \tview->col = 0;\n \tview->curline = line;\n \tview->curtype = LINE_NONE;\n@@ -2094,6 +2094,11 @@ draw_view_line(struct view *view, unsigned int lineno)\n \t\tset_view_attr(view, LINE_CURSOR);\n \t\tline->selected = TRUE;\n \t\tview->ops->select(view, line);\n+\t} else if (cleareol) {\n+\t\t/* FIXME: It is not strictly correct to only clear to\n+\t\t * the line end for non-selected lines. However, no view\n+\t\t * currently requires clearing for the first line. */\n+\t\twclrtoeol(view->win);\n \t}\n \n \treturn view->ops->draw(view, line, lineno);\n-- \n1.6.2.rc1.209.gfe624.dirty\n\n"},{"id":"105651","messageId":"499F143B.7080708@tedpavlic.com","threadId":"17595","inReplyTo":"2c6b72b30902201034r47850c8aq248b673ee96bdf3a@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Ted Pavlic","fromEmail":"ted@tedpavlic.com","sentAt":"2009-02-20T20:36:11Z","receivedAt":"2009-02-20T20:36:11Z","isPatch":false,"sender":{"key":"ted@tedpavlic.com","avatar":"https://gravatar.com/avatar/d085392370ff4c028cf17a0e81e0647744c9682fbcb36b499f31d08ef80ef569?d=mp&s=160"},"body":"Both patches (the new and the old) seem to fix the original problem.\n\nHowever, I now notice that both patches introduces a new problem. From \nthe tig repo (with no .tigrc), I run tig to view the single-line \nchangelog. I then hit \"Enter\" to view the first commit (which is your \nfix). I then hit \"j\" and \"k\" to scroll through it.\n\n*Sometimes* the entire line gets highlighted with a green background, \nand *sometimes* it doesn't (i.e., sometimes the green background doesn't \nhighlight the whitespace between the end of the line and the right-hand \nside of the terminal, and sometimes it does). That is, if I hold down \n\"j\" to scroll through the commit, and then hold down \"k\" to scroll back, \nlines that were highlighted all the way from left to right on the way \ndown are only highlighted part of the way on the way up.\n\n--Ted\n\nOn 2/20/09 1:34 PM, Jonas Fonseca wrote:\n> On Fri, Feb 20, 2009 at 18:24, Ted Pavlic wrote:\n>>> Looks like there might be a pattern and I might have an excuse to go\n>>> knock on the door of one of my \"Mac\" friends. ;) However, first I\n>>> would kindly ask if one of you have time to test the attached patch.\n>> Any verdict on this patch (it WFM)? I notice tig is still unpatched to fix\n>> this problem.\n>\n> I didn't look more into it. Maybe you can try the attached patch for me.\n>\n\n-- \nTed Pavlic \n\n Please visit my ALS association page:\n http://web.alsa.org/goto/tedpavlic\n My family appreciates your support in the fight to defeat ALS.\n"},{"id":"105668","messageId":"2c6b72b30902201531n12243e2cv7bb671048ca6cf76@mail.gmail.com","threadId":"17595","inReplyTo":"499F143B.7080708@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-20T23:31:34Z","receivedAt":"2009-02-20T23:31:34Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Fri, Feb 20, 2009 at 21:36, Ted Pavlic wrote:\n> Both patches (the new and the old) seem to fix the original problem.\n>\n> However, I now notice that both patches introduces a new problem. From the\n> tig repo (with no .tigrc), I run tig to view the single-line changelog. I\n> then hit \"Enter\" to view the first commit (which is your fix). I then hit\n> \"j\" and \"k\" to scroll through it.\n\nHmm. I probably won't be able to look at this before sometime in April. Sorry.\n\n-- \nJonas Fonseca\n"},{"id":"105669","messageId":"2c6b72b30902201535q2466b8fbtce746a5263ebf320@mail.gmail.com","threadId":"17595","inReplyTo":"op.upgqjej6a8ed4e@dellschleppa","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-20T23:35:59Z","receivedAt":"2009-02-20T23:35:59Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Mon, Feb 16, 2009 at 22:12, Tilo Schwarz wrote:\n> On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca \n> wrote:\n>\n>> I have thought about it. The question is if a separate view is\n>> necessary or if the main view would do.\n>\n> I'm not sure if I understood it correctly. Do you mean, only commits are\n> shown, which are heads of some branch? If so, what if more than one head\n> points to the same commit?\n\nTrue, it is not very intuitive with more than one branch perhaps.\nHowever, I still think there is some overlap between a branch view,\nthe main view and possible also the status view. From the status view\nyou might want to create a new branch based on changes, and in the\nmain view you might want to create a branch to help backport a bugfix.\n\n> I think I would prefer a branch view, because then one could also have a\n> branch-view keymap with specialized commands. One possibility would be (just\n> as example):\n\nMaybe it is best to keep it simple and focus on your idea first and\nmake tig at least aware of branches. And yes, it makes sense with an\nnew keymap.\n\n> The view shows something like this (here an example from the tig git\n> repository)\n>\n> master\n> * my_feature_bar\n> X my_feature_foo\n> origin/HEAD\n> origin/master\n> origin/release\n\nOK, I have added the begining structure for a branch view, bound to\n'H' by default. It does not support any actions besides refreshing and\nviewing the branch history. So there is still some work to achieve the\neasy access to branch commands.\n\n>> bind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)\n>\n> Ahh, ok, so tig would issue a prompt and ask me for the name?\n\nYeah, I don't know if it will be useful.\n\n> BTW, is the git list the right list to discuss bugs / patches for tig?\n\nYes please.\n\n-- \nJonas Fonseca\n"},{"id":"105732","messageId":"op.uppptmu7a8ed4e@dellschleppa","threadId":"17595","inReplyTo":"2c6b72b30902201535q2466b8fbtce746a5263ebf320@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-21T17:35:36Z","receivedAt":"2009-02-21T17:35:36Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca \n wrote:\n\n[...]\n> OK, I have added the begining structure for a branch view, bound to\n> 'H' by default. It does not support any actions besides refreshing and\n> viewing the branch history. So there is still some work to achieve the\n> easy access to branch commands.\n\nThat's really nice!\n\n>> BTW, is the git list the right list to discuss bugs / patches for tig?\n>\n> Yes please.\n\nOk, here we go ;-).\n\nI can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555\nlike this, using the tig repo itself:\n\n- Start ./tig --all\n- Enter the new branch view pressing 'H'\n- Add a new branch foo using git checkout -b foo on some\n console or in tig using ':checkout -b foo'\n- Press F5 in the branch view to reload\n- Move cursor on the new branch foo\n- Press ENTER\n\nThen I get a SIGSEGV in line\n\n6150 if (ref->head)\n\n(gdb) print *ref\nCannot access memory at address 0x2d676974\n\n#0 0x08056427 in main_draw (view=0x8060500, line=0x9b61638, lineno=0) at \ntig.c:6150\n#1 0x0804d19d in draw_view_line (view=0x8060500, lineno=0) at tig.c:2111\n#2 0x0804d269 in redraw_view_from (view=0x8060500, lineno=0) at tig.c:2141\n#3 0x0804d2bf in redraw_view (view=0x8060500) at tig.c:2152\n#4 0x0804f70b in open_view (prev=0x8062fa8, request=REQ_VIEW_MAIN, \nflags=OPEN_SPLIT) at tig.c:3055\n#5 0x08053241 in branch_request (view=0x8062fa8, request=REQ_ENTER, \nline=0x9b6b038) at tig.c:4783\n#6 0x0804f9df in view_driver (view=0x8062fa8, request=REQ_ENTER) at \ntig.c:3142\n#7 0x080594a3 in main (argc=Cannot access memory at address 0x3\n\nI tried to track this down, but was not successful yet (having seen tig.c \nthe first time today). I looked in get_refs and read_ref, but couldn't \nnail it down up to now. It feels, as if the refresh does find and update \nthe new branch foo, but the corresponding commit->refs are not properly \nupdated (just guessing).\n\nBest regards & thank you for tig!\n\n Tilo\n"},{"id":"105733","messageId":"2c6b72b30902210941u2b3e138dh903488e4dc4d7712@mail.gmail.com","threadId":"17595","inReplyTo":"op.uppptmu7a8ed4e@dellschleppa","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"jonas.fonseca@gmail.com","sentAt":"2009-02-21T17:41:51Z","receivedAt":"2009-02-21T17:41:51Z","isPatch":false,"sender":{"key":"jonas.fonseca@gmail.com","avatar":"https://gravatar.com/avatar/9b7fa23cce50269e5d164312b6ac5ae818a180f837b38f28f3bdf689dd7f96cd?d=mp&s=160"},"body":"On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz wrote:\n> On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca \n> wrote:\n> Ok, here we go ;-).\n>\n> I can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555\n> like this, using the tig repo itself:\n\nShould be fixed already in commit\n129cf793c915ac00dac86c561c25099cd3cd4be0 (Fix reloading of references\nto not cause access to freed memory).\n\n-- \nJonas Fonseca\n"},{"id":"105742","messageId":"op.uppxcehra8ed4e@dellschleppa","threadId":"17595","inReplyTo":"2c6b72b30902210941u2b3e138dh903488e4dc4d7712@mail.gmail.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Tilo Schwarz","fromEmail":"tilo@tilo-schwarz.de","sentAt":"2009-02-21T20:18:04Z","receivedAt":"2009-02-21T20:18:04Z","isPatch":false,"sender":{"key":"tilo@tilo-schwarz.de","avatar":null},"body":"On Sat, 21 Feb 2009 18:41:51 +0100, Jonas Fonseca \n wrote:\n\n> On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz wrote:\n>> On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca \n>> \n>> wrote:\n>> Ok, here we go ;-).\n>>\n>> I can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555\n>> like this, using the tig repo itself:\n>\n> Should be fixed already in commit\n> 129cf793c915ac00dac86c561c25099cd3cd4be0 (Fix reloading of references\n> to not cause access to freed memory).\n\nThat was quick! I can't trigger the SIGSEGV anymore.\n\nRegards,\n\n Tilo\n"},{"id":"106264","messageId":"2c6b72b30902251354k25cf97dfh66a3026385f5aa8d@mail.gmail.com","threadId":"17595","inReplyTo":"499F143B.7080708@tedpavlic.com","subject":"Re: [ANNOUNCE] tig-0.14","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2009-02-25T21:54:38Z","receivedAt":"2009-02-25T21:54:38Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Fri, Feb 20, 2009 at 21:36, Ted Pavlic wrote:\n> Both patches (the new and the old) seem to fix the original problem.\n>\n> However, I now notice that both patches introduces a new problem.\n\nI finally found a way to reproduce and bisect this today on a linux\nbox with ncurses-5.5 installed. To double check can you please try\nthis third version?\n\n-- \nJonas Fonseca\n\n\nFrom 5458881439b362b6d729500bc7d67bd100cdd8b4 Mon Sep 17 00:00:00 2001\nFrom: Jonas Fonseca \nDate: Tue, 10 Feb 2009 21:33:18 +0100\nSubject: [PATCH] Fix regression where a line was not cleared when not selected anymore\n\nIntroduced in 792d0e0931fb8785135a6b5d250a570a597c7324 which tried to\neliminated unneeded calls to redrawwin(). However, for older ncurses\nversions (5.5) this caused problems. To fix this explicitly mark newly\nselected lines using wtouchln(), so they are properly redrawn.\n---\n tig.c | 10 ++++++++--\n 1 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/tig.c b/tig.c\nindex 2a3ab3a..df2b4f6 100644\n--- a/tig.c\n+++ b/tig.c\n@@ -2073,6 +2073,7 @@ draw_view_line(struct view *view, unsigned int lineno)\n {\n \tstruct line *line;\n \tbool selected = (view->offset + lineno == view->lineno);\n+\tbool cleareol;\n \n \tassert(view_is_displayed(view));\n \n@@ -2080,10 +2081,9 @@ draw_view_line(struct view *view, unsigned int lineno)\n \t\treturn FALSE;\n \n \tline = &view->line[view->offset + lineno];\n+\tcleareol = line->cleareol || (line->selected && !selected);\n \n \twmove(view->win, lineno, 0);\n-\tif (line->cleareol)\n-\t\twclrtoeol(view->win);\n \tview->col = 0;\n \tview->curline = line;\n \tview->curtype = LINE_NONE;\n@@ -2094,6 +2094,12 @@ draw_view_line(struct view *view, unsigned int lineno)\n \t\tset_view_attr(view, LINE_CURSOR);\n \t\tline->selected = TRUE;\n \t\tview->ops->select(view, line);\n+\t\ttouchline(view->win, lineno, 1);\n+\t} else if (cleareol) {\n+\t\t/* FIXME: It is not strictly correct to only clear to\n+\t\t * the line end for non-selected lines. However, no view\n+\t\t * currently requires clearing for the first line. */\n+\t\twclrtoeol(view->win);\n \t}\n \n \treturn view->ops->draw(view, line, lineno);\n-- \n1.6.2.rc1.209.gfe624.dirty\n\n"}]}