[ANNOUNCE] tig-0.14

[ANNOUNCE] tig-0.14

[Jonas Fonseca]

Hello,

Here is a much needed update fixing multiple regressions from the
introduction of the IO API in 0.13. Among improvements is the much
requested ability to restore the position in the stage view when staging
diff hunks. Also noteworthy is the many optimizations of the screen
updating to make it work better across slow links. Finally, beware that
a handful of incompatibilities can cause problems.

What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.

 - Homepage:	http://jonas.nitro.dk/tig/
 - Manual:	http://jonas.nitro.dk/tig/manual.html
 - Tarballs:	http://jonas.nitro.dk/tig/releases/
 - Git URL:	git://repo.or.cz/tig.git 
 - Gitweb:	http://repo.or.cz/w/tig.git

Release notes
-------------
Incompatibilities:

 - The screen-resize action has been deprecated. It had no real use for
   users and was never meant to be exposed.
 - The "tree-parent" action was renamed to "parent". Warnings will be
   emitted for transition.
 - Remove parsing of deprecated option -S and subcommands log and diff.
 - The "author" color replaces "main-author". Setting the latter will
   now set the "author" color.

Improvements:

 - Horizontal scrolling. Bound to Left/Right by default.
 - Read tigrc(5) options from git configuration files using the syntax:

	[tig] show-rev-graph = true
	[tig "color"] cursor = yellow red bold 
	[tig "bind"] generic = P parent

 - Tree view: avoid flickering when updating.
 - Tree view: annotate entries with commit information.
 - Tree & blob view: open any blob in an editor.
 - Stage & main view: restore view position when reloading.
 - Blame view: load blame for parent commit. For merge commits the parent
   is queried. Bound to ',' by default via the existing "parent" action.
 - Abbreviate author names to initials when the width of the author column
   is below 6 characters.

Bug fixes:

 - Tree view: fix memory corruption bug when updating.
 - Tree view: improve handling of empty trees.
 - Status view: fix reverting of unmerged files.
 - Fix regression for non-UTF-8 locales corrupting the view data.
 - Fix regression parsing multiple spaces in ~/.tigrc.

Change summary
--------------
The diffstat and log summary for changes made in this release.

 BUGS                |    2 -
 INSTALL             |    2 +-
 Makefile            |   22 +-
 NEWS                |   43 +-
 TODO                |   58 +-
 VERSION             |    2 +-
 contrib/aspell.dict |  147 ++++
 contrib/release.sh  |   75 ++
 manual.txt          |   48 +-
 tig.1.txt           |   14 +-
 tig.c               | 1784 +++++++++++++++++++++++++++----------------
 tigrc.5.txt         |   91 ++-
 12 files changed, 1520 insertions(+), 768 deletions(-)

     1	Jeff King
    76	Jonas Fonseca
     1	Stefan Naewe

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[bill lam]

Thank you for the update!

There is a choice in "git add -i" call patch/hunks.  Is this the same
as the update/chunks as described in tig manual?

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩110 杜甫  天末懷李白
    涼風起天末  君子意如何  鴻雁幾時到  江湖秋水多
    文章憎命達  魑魅喜人過  應共冤魂語  投詩贈汨羅

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

2009/2/6 bill lam <cbill.lam@gmail.com>:
> There is a choice in "git add -i" call patch/hunks.  Is this the same
> as the update/chunks as described in tig manual?

Yes, you can stage individual path hunks (I should probably use the
git terminology) using 'u' in the stage view. Use '@' to navigate to
the next path hunk.

Two things tig does not (yet) support is splitting and editing a hunk.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Sitaram Chamarty]

On 2009-02-06, Jonas Fonseca <fonseca@diku.dk> wrote:
> Two things tig does not (yet) support is splitting and editing a hunk.

But I must say that the last time I did this, the hunks that
tig showed me were more granular than what 'git gui' did; no
idea why.  To do what I wanted to do in 'git gui' was
possible, by staging line by line instead of hunk by hunk,
but I didn't fancy all that clicking and tig saved me.

So... thanks!

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 2009-02-06, Jonas Fonseca <fonseca@diku.dk> wrote:
>> Two things tig does not (yet) support is splitting and editing a hunk.
>
> But I must say that the last time I did this, the hunks that
> tig showed me were more granular than what 'git gui' did; no
> idea why.  To do what I wanted to do in 'git gui' was
> possible, by staging line by line instead of hunk by hunk,
> but I didn't fancy all that clicking and tig saved me.

Great to hear. I sometimes, miss though, being able to lower the diff
context to 1 or 2, however, maybe I should learn to commit more often
instead.

-- 
Jonas Fonseca

showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14

[Sitaram Chamarty]

On 2009-02-08, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty <sitaramc@gmail.com> wrote:

>> But I must say that the last time I did this, the hunks that
>> tig showed me were more granular than what 'git gui' did; no
>> idea why.  To do what I wanted to do in 'git gui' was
>> possible, by staging line by line instead of hunk by hunk,
>> but I didn't fancy all that clicking and tig saved me.

> Great to hear. I sometimes, miss though, being able to lower the diff
> context to 1 or 2, however, maybe I should learn to commit more often
> instead.

Is there any way to see the sha1 of the parent commit in any
of the displays, like gitk does?

I know you're only parsing the 4 or 5 basic git commands,
and none of those do, so I guess I know the answer :-( but
it doesn't hurt to ask.

Re: showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> Is there any way to see the sha1 of the parent commit in any
> of the displays, like gitk does?
>
> I know you're only parsing the 4 or 5 basic git commands,
> and none of those do, so I guess I know the answer :-( but
> it doesn't hurt to ask.

It is sort of possible by setting the TIG_DIFF_CMD environment
variable to something appropriate, for example using (and I don't know
if this will be formatted correctly):

export TIG_DIFF_CMD='git show -p --stat -C -M
--pretty=format:commit%x20%H%d%nAuthor:%x20%an%x20<%ae>%x20%ai%nParent:%x20%P%nSubject:%x20%s%n%n%b
%(commit)'

You need to avoid using space except for where it really separates
arguments, which is why the obscure %x20 is used. ;)

Another solution would be to create a script, which just expects the
commit SHA1 as its first argument and then do the formatting there and
then use:

export TIG_DIFF_CMD="/my/script %(commit)"

-- 
Jonas Fonseca

Re: showing SHA1 of parent commit in tig [was Re: [ANNOUNCE] tig-0.14

[Sitaram Chamarty]

On 2009-02-12, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> Is there any way to see the sha1 of the parent commit in any
>> of the displays, like gitk does?
>>
>> I know you're only parsing the 4 or 5 basic git commands,
>> and none of those do, so I guess I know the answer :-( but
>> it doesn't hurt to ask.
>
> It is sort of possible by setting the TIG_DIFF_CMD environment
> variable to something appropriate, for example using (and I don't know
> if this will be formatted correctly):
>
> export TIG_DIFF_CMD='git show -p --stat -C -M
> --pretty=format:commit%x20%H%d%nAuthor:%x20%an%x20<%ae>%x20%ai%nParent:%x20%P%nSubject:%x20%s%n%n%b
> %(commit)'
>
> You need to avoid using space except for where it really separates
> arguments, which is why the obscure %x20 is used. ;)
>
> Another solution would be to create a script, which just expects the
> commit SHA1 as its first argument and then do the formatting there and
> then use:
>
> export TIG_DIFF_CMD="/my/script %(commit)"

OK thanks -- I'll give that a shot when I get a chance.

Regards,

Sitaram

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:

>  - Blame view: load blame for parent commit. For merge commits the parent
>    is queried. Bound to ',' by default via the existing "parent" action.

Thanks for this, btw. I've already used it at least half a dozen times
in the past week or so.

It looks like you just keep the view on the same line number when moving
to the new blame output. In practice, this has very mixed results. Most
of the time it does exactly what I want, but if the file changes
significantly, you get dumped at a totally unrelated part of the file.
I'm not sure if there is a more clever solution, though.

-Peff

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 6, 2009 at 20:15, Jeff King <peff@peff.net> wrote:
> On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:
>
>>  - Blame view: load blame for parent commit. For merge commits the parent
>>    is queried. Bound to ',' by default via the existing "parent" action.
>
> Thanks for this, btw. I've already used it at least half a dozen times
> in the past week or so.

Good to hear. I remember you posted a patch for this after 0.11 was
released last April.

> It looks like you just keep the view on the same line number when moving
> to the new blame output. In practice, this has very mixed results. Most
> of the time it does exactly what I want, but if the file changes
> significantly, you get dumped at a totally unrelated part of the file.
> I'm not sure if there is a more clever solution, though.

Yes, it is a bit easy to get lost. It should be possible to find the
original line number either by making git-blame also honor
--show-number for the --incremental output or by using the "porcelain"
version:

  git blame --show-number -L <line>,<line> <rev> <file>

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jakub Narebski]

Jonas Fonseca <fonseca@diku.dk> writes:

> On Fri, Feb 6, 2009 at 20:15, Jeff King <peff@peff.net> wrote:
> > On Thu, Feb 05, 2009 at 09:44:36PM +0100, Jonas Fonseca wrote:
>>
>>>  - Blame view: load blame for parent commit. For merge commits the parent
>>>    is queried. Bound to ',' by default via the existing "parent" action.

>> It looks like you just keep the view on the same line number when moving
>> to the new blame output. In practice, this has very mixed results. Most
>> of the time it does exactly what I want, but if the file changes
>> significantly, you get dumped at a totally unrelated part of the file.
>> I'm not sure if there is a more clever solution, though.
> 
> Yes, it is a bit easy to get lost. It should be possible to find the
> original line number either by making git-blame also honor
> --show-number for the --incremental output or by using the "porcelain"
> version:
> 
>   git blame --show-number -L <line>,<line> <rev> <file>

Errr... you are wrong.  There are three line numbers when browsing
blame output.  Original line number, line number in _blamed_ commit
(shown with --show-number, --porcelain, --incremental), and line
number in _parent_ of blamed commit... which we don't know, and
which I don't think it is easy to find...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 6, 2009 at 23:53, Jakub Narebski <jnareb@gmail.com> wrote:
> Jonas Fonseca <fonseca@diku.dk> writes:
>> It should be possible to find the
>> original line number either by making git-blame also honor
>> --show-number for the --incremental output or by using the "porcelain"
>> version:
>>
>>   git blame --show-number -L <line>,<line> <rev> <file>
>
> Errr... you are wrong.  There are three line numbers when browsing
> blame output.  Original line number, line number in _blamed_ commit
> (shown with --show-number, --porcelain, --incremental), and line
> number in _parent_ of blamed commit... which we don't know, and
> which I don't think it is easy to find...

Yes, I was not aware of the original line number being there. Anyway,
tig now uses this to jump to the right line when the user requests to
show blame for specific commit.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Fri, Feb 06, 2009 at 11:10:23PM +0100, Jonas Fonseca wrote:

> > It looks like you just keep the view on the same line number when moving
> > to the new blame output. In practice, this has very mixed results. Most
> > of the time it does exactly what I want, but if the file changes
> > significantly, you get dumped at a totally unrelated part of the file.
> > I'm not sure if there is a more clever solution, though.
> 
> Yes, it is a bit easy to get lost. It should be possible to find the
> original line number either by making git-blame also honor
> --show-number for the --incremental output or by using the "porcelain"
> version:
> 
>   git blame --show-number -L <line>,<line> <rev> <file>

I'm not sure that will always work. You know that in some version of the
file, line number X is of interest to you. You want to find the "same"
spot in the parent commit. So you can:

  1. use the line number in the blamed file; this doesn't work because
     the re-blamed file may have much more or less content before X,
     which is going to shift the content of interest.

  2. use the line number that the content was introduced on in the blamed
     commit. This has the same problem as above, but may be more
     accurate because you are only jumping _one_ revision to the parent
     of the blamed commit (instead of from wherever you started
     blaming).

My impression is that tig is currently doing (1).  I think (2) will
suffer from the same problem, but in practice the margin of error will
be much smaller because your are rewinding through fewer changes. So if
that is what you were suggesting, I think it is probably worth trying.

It would require a "reload and jump to this arbitrary line" function,
which I remember being problematic when I did my original patch a long
time ago.  But I haven't looked at the new code to see if it is easier
now (it looks like you have been doing quite a bit of refactoring in
that area lately).

You could also try matching up content, but that is equally error-prone.
You can't find the same line in the parent, for the obvious reason that
you've just blamed it, so by definition it doesn't exist in the parent.
You could try doing a fuzzy match on the surrounding blamed lines, but
there is no guarantee that they exist in the parent commit, either. So I
think the line number guess is probably our best bet.

-Peff

Re: [ANNOUNCE] tig-0.14

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> My impression is that tig is currently doing (1).  I think (2) will
> suffer from the same problem, but in practice the margin of error will
> be much smaller because your are rewinding through fewer changes. So if
> that is what you were suggesting, I think it is probably worth trying.

It has been quite a while since I did the "show previous" feature of
"git-blame --porcelain" that has been forever queued in 'next'; if I
remember correctly, it implemented (2).

The reason why it never graduated from 'next' is exactly this issue.  By
definition, there is no "previous" line number (if there were such a thing
that says "This line was at line N in the parent of the blamed commit",
then the commit wouldn't have taken the blame but would have passed it
down to the parent), and we need to come up with a reasonable heuristics.

So perhaps this discussion would motivate somebody to finish that part
off, and tig and other Porcelains can just read the necessary line number
from the git-blame output.

Re: [ANNOUNCE] tig-0.14

[david]

On Fri, 6 Feb 2009, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
>
>> My impression is that tig is currently doing (1).  I think (2) will
>> suffer from the same problem, but in practice the margin of error will
>> be much smaller because your are rewinding through fewer changes. So if
>> that is what you were suggesting, I think it is probably worth trying.
>
> It has been quite a while since I did the "show previous" feature of
> "git-blame --porcelain" that has been forever queued in 'next'; if I
> remember correctly, it implemented (2).
>
> The reason why it never graduated from 'next' is exactly this issue.  By
> definition, there is no "previous" line number (if there were such a thing
> that says "This line was at line N in the parent of the blamed commit",
> then the commit wouldn't have taken the blame but would have passed it
> down to the parent), and we need to come up with a reasonable heuristics.
>
> So perhaps this discussion would motivate somebody to finish that part
> off, and tig and other Porcelains can just read the necessary line number
> from the git-blame output.

this sounds like the same basic problem I was having around the begninning 
of the year (thread subject 'how to track the history of a line in a 
file') what I ended up doing was to use git blame to go back and find the 
commit where a line was introduced, then use git diff to find the changes, 
then find the hunk of the diff that introduced the line, then find the 
lines that were removed and trace them back (repeating the process)

David Lang

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sat, Feb 7, 2009 at 09:55,  <david@lang.hm> wrote:
> On Fri, 6 Feb 2009, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>> My impression is that tig is currently doing (1).  I think (2) will
>>> suffer from the same problem, but in practice the margin of error will
>>> be much smaller because your are rewinding through fewer changes. So if
>>> that is what you were suggesting, I think it is probably worth trying.

Tig wasn't using the line number or even the filename, this has now been fixed.

>> It has been quite a while since I did the "show previous" feature of
>> "git-blame --porcelain" that has been forever queued in 'next'; if I
>> remember correctly, it implemented (2).
>>
>> The reason why it never graduated from 'next' is exactly this issue.  By
>> definition, there is no "previous" line number (if there were such a thing
>> that says "This line was at line N in the parent of the blamed commit",
>> then the commit wouldn't have taken the blame but would have passed it
>> down to the parent), and we need to come up with a reasonable heuristics.

So it ist somewhat safe to assume that the line didn't originate from
a different file, since git-blame would have picked that up?

> this sounds like the same basic problem I was having around the begninning
> of the year (thread subject 'how to track the history of a line in a file')
> what I ended up doing was to use git blame to go back and find the commit
> where a line was introduced, then use git diff to find the changes, then
> find the hunk of the diff that introduced the line, then find the lines that
> were removed and trace them back (repeating the process)

I've tried to implement something like this by using the output of
"git-diff-tree -U0". One problem it does not yet handle is the
cut'n'paste within the same file where the deleted line ends up in a
different hunk. So it won't jump to the correct place if you try to
trace back for example the origin of the parse_options function in
tig.c since at some point I moved it down in the file. However, it
does work quite well for tracing back the origin of for example the
DATE_COLS macro which was rewritten a few times.

I guess it comes down to what you can assume about the features or
"uniqueness" of the line (or lines) that are being traced back and
whether the history and commits are well organized.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca <fonseca@diku.dk> wrote:
> One problem it does not yet handle is the
> cut'n'paste within the same file where the deleted line ends up in a
> different hunk.

Hmm, this is trivially fixed by passing -M to git blame so maybe that
should just be the default for tig.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Sun, Feb 08, 2009 at 11:55:55AM +0100, Jonas Fonseca wrote:

> On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca <fonseca@diku.dk> wrote:
> > One problem it does not yet handle is the
> > cut'n'paste within the same file where the deleted line ends up in a
> > different hunk.
> 
> Hmm, this is trivially fixed by passing -M to git blame so maybe that
> should just be the default for tig.

Yes, I think that is worth doing. It might also be nice to show the
original filename in the blame output (perhaps optionally if it is
different than the original). However, you might want to look at how
"git gui blame" does it. It actually shows _two_ entries for each line:
the origin of the content, and the commit that moved the content into
place.

I don't know if that is worth doing in tig or not; I think you generally
want to assume a much more constrained screen size (though I have to
admit that I generally maximize my terminal to use "tig blame" anyway --
80x25 just doesn't cut it).

-Peff

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sun, Feb 8, 2009 at 12:06, Jeff King <peff@peff.net> wrote:
> On Sun, Feb 08, 2009 at 11:55:55AM +0100, Jonas Fonseca wrote:
>
>> On Sun, Feb 8, 2009 at 11:47, Jonas Fonseca <fonseca@diku.dk> wrote:
>> > One problem it does not yet handle is the
>> > cut'n'paste within the same file where the deleted line ends up in a
>> > different hunk.
>>
>> Hmm, this is trivially fixed by passing -M to git blame so maybe that
>> should just be the default for tig.
>
> Yes, I think that is worth doing. It might also be nice to show the
> original filename in the blame output (perhaps optionally if it is
> different than the original). However, you might want to look at how
> "git gui blame" does it. It actually shows _two_ entries for each line:
> the origin of the content, and the commit that moved the content into
> place.
>
> I don't know if that is worth doing in tig or not; I think you generally
> want to assume a much more constrained screen size (though I have to
> admit that I generally maximize my terminal to use "tig blame" anyway --
> 80x25 just doesn't cut it).

I wouldn't mind not showing the date and sha1 columns. The sha1 column
is mustly there to give a clue about what lines are from the same
commit, but that could be done better using the ideas from git-gui.

Will look into it when I get some more time ...

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Fri, Feb 06, 2009 at 11:28:05PM -0800, Junio C Hamano wrote:

> It has been quite a while since I did the "show previous" feature of
> "git-blame --porcelain" that has been forever queued in 'next'; if I
> remember correctly, it implemented (2).
> 
> The reason why it never graduated from 'next' is exactly this issue.  By
> definition, there is no "previous" line number (if there were such a thing
> that says "This line was at line N in the parent of the blamed commit",
> then the commit wouldn't have taken the blame but would have passed it
> down to the parent), and we need to come up with a reasonable heuristics.
> 
> So perhaps this discussion would motivate somebody to finish that part
> off, and tig and other Porcelains can just read the necessary line number
> from the git-blame output.

Do we actually have heuristics that are better than "this was the line
in the original source file?" (i.e., (2) as I described). Because we
already have that in the first number that comes from "blame
--incremental". So perhaps we should start using it and see how well it
works in practice (because like all heuristics, getting a good one is
likely to be a lot of guess and check on what works in practice).

Of course I say "we" and I mean "Jonas". ;) I worked up a small tig
patch below which seems to work, but:

  1. the "jump to this new line number on refresh" code is very hack-ish
     (read: it is now broken for every view except blame), and I'm not
     sure of the most tig-ish way of fixing it

  2. I'm very unsure of the line number parsing. The parse_number
     function confusingly parses " 123 456" as "456". So perhaps there
     is some invariant of the parsing strategy that I don't understand
     (like our pointer is supposed to be at the last character of the
     previous token and _not_ on the space). So the parsing in
     parse_blame_commit is a bit hack-ish.

  3. Nothing in tig records the file that the source line came from. So
     we could be jumping to an arbitrary line number that really came
     from some other file.

Anyway, here it is.

---
diff --git a/tig.c b/tig.c
index 97794b0..faec056 100644
--- a/tig.c
+++ b/tig.c
@@ -38,6 +38,7 @@
 #include <unistd.h>
 #include <time.h>
 #include <fcntl.h>
+#include <limits.h>
 
 #include <regex.h>
 
@@ -2574,7 +2575,7 @@ reset_view(struct view *view)
 
 	view->p_offset = view->offset;
 	view->p_yoffset = view->yoffset;
-	view->p_lineno = view->lineno;
+	/* view->p_lineno = view->lineno; */
 
 	view->line = NULL;
 	view->offset = 0;
@@ -4180,6 +4181,7 @@ struct blame_commit {
 
 struct blame {
 	struct blame_commit *commit;
+	int lineno;
 	char text[1];
 };
 
@@ -4243,14 +4245,16 @@ parse_blame_commit(struct view *view, const char *text, int *blamed)
 {
 	struct blame_commit *commit;
 	struct blame *blame;
-	const char *pos = text + SIZEOF_REV - 1;
+	const char *pos = text + SIZEOF_REV - 2;
 	size_t lineno;
 	size_t group;
+	size_t orig_lineno;
 
-	if (strlen(text) <= SIZEOF_REV || *pos != ' ')
+	if (strlen(text) <= SIZEOF_REV || pos[1] != ' ')
 		return NULL;
 
-	if (!parse_number(&pos, &lineno, 1, view->lines) ||
+	if (!parse_number(&pos, &orig_lineno, 1, INT_MAX) ||
+	    !parse_number(&pos, &lineno, 1, view->lines) ||
 	    !parse_number(&pos, &group, 1, view->lines - lineno + 1))
 		return NULL;
 
@@ -4264,6 +4268,7 @@ parse_blame_commit(struct view *view, const char *text, int *blamed)
 
 		blame = line->data;
 		blame->commit = commit;
+		blame->lineno = orig_lineno + group - 1;
 		line->dirty = 1;
 	}
 
@@ -4425,8 +4430,10 @@ blame_request(struct view *view, enum request request, struct line *line)
 
 	case REQ_PARENT:
 		if (check_blame_commit(blame) &&
-		    select_commit_parent(blame->commit->id, opt_ref))
+		    select_commit_parent(blame->commit->id, opt_ref)) {
+			view->p_lineno = blame->lineno;
 			open_view(view, REQ_VIEW_BLAME, OPEN_REFRESH);
+		}
 		break;
 
 	case REQ_ENTER:

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sat, Feb 7, 2009 at 08:10, Jeff King <peff@peff.net> wrote:
> It would require a "reload and jump to this arbitrary line" function,
> which I remember being problematic when I did my original patch a long
> time ago.  But I haven't looked at the new code to see if it is easier
> now (it looks like you have been doing quite a bit of refactoring in
> that area lately).

Yes, support for restoring/jumping to an arbitrary line is possible by
setting the view lineno and then call open_view with the OPEN_REFRESH
flag.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Sun, Feb 08, 2009 at 11:31:43AM +0100, Jonas Fonseca wrote:

> On Sat, Feb 7, 2009 at 08:10, Jeff King <peff@peff.net> wrote:
> > It would require a "reload and jump to this arbitrary line" function,
> > which I remember being problematic when I did my original patch a long
> > time ago.  But I haven't looked at the new code to see if it is easier
> > now (it looks like you have been doing quite a bit of refactoring in
> > that area lately).
> 
> Yes, support for restoring/jumping to an arbitrary line is possible by
> setting the view lineno and then call open_view with the OPEN_REFRESH
> flag.

I just tried out the version you pushed today (which has both the
cleaner version of my patch and the guesstimation patch). It behaves
exactly as I would expect. Thanks so much for looking into this.

I do have one more complaint, though. :)

If you parent-blame far enough, you will reach a point before the file
existed at all, in which case blame_read_file will die() with an error.
It would be nice to print an error and stay on the same screen. Below is
a patch which implements (I think) reasonably elegant solution.

-- >8 --
handle blaming beyond the creation of file more gracefully

Currently when you ask to re-blame from the parent of a
commit that created the file, blame_read_file will complain
that it cannot get the file contents ("No blame exist").

At the time we try to read the file, it is too late to abort
the operation, as we have already changed to the new blame
view. However, we can detect this situation early by
limiting the selection of the parent revision to the
particular path of interest: if it returns a parent even
with path-limiting, then we know the path exists; if not,
then we know it doesn't.

Signed-off-by: Jeff King <peff@peff.net>
---
 tig.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tig.c b/tig.c
index 04a44db..28fae2c 100644
--- a/tig.c
+++ b/tig.c
@@ -3384,11 +3384,11 @@ select_commit_parent_handler(void *data, char *buf, int c)
 }
 
 static bool
-select_commit_parent(const char *id, char rev[SIZEOF_REV])
+select_commit_parent(const char *id, char rev[SIZEOF_REV], const char *path)
 {
 	char buf[SIZEOF_STR * 4];
 	const char *revlist_argv[] = {
-		"git", "rev-list", "-1", "--parents", id, NULL
+		"git", "rev-list", "-1", "--parents", id, "--", path, NULL
 	};
 	int parents;
 
@@ -3399,7 +3399,10 @@ select_commit_parent(const char *id, char rev[SIZEOF_REV])
 		return FALSE;
 
 	} else if (parents == 0) {
-		report("The selected commit has no parents");
+		if (path)
+			report("path '%s' does not exist in the parent", path);
+		else
+			report("The selected commit has no parents");
 		return FALSE;
 	}
 
@@ -4468,7 +4471,8 @@ blame_request(struct view *view, enum request request, struct line *line)
 
 	case REQ_PARENT:
 		if (check_blame_commit(blame) &&
-		    select_commit_parent(blame->commit->id, opt_ref)) {
+		    select_commit_parent(blame->commit->id, opt_ref,
+					 blame->commit->filename)) {
 			string_copy(opt_file, blame->commit->filename);
 			setup_blame_parent_line(view, blame);
 			open_view(view, REQ_VIEW_BLAME, OPEN_REFRESH);
-- 
1.6.1.2.553.gdd056.dirty

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sun, Feb 8, 2009 at 12:00, Jeff King <peff@peff.net> wrote:
> I do have one more complaint, though. :)
>
> If you parent-blame far enough, you will reach a point before the file
> existed at all, in which case blame_read_file will die() with an error.
> It would be nice to print an error and stay on the same screen. Below is
> a patch which implements (I think) reasonably elegant solution.

OK, will apply.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Mikael Magnusson]

2009/2/5 Jonas Fonseca <fonseca@diku.dk>:
> Hello,
>
> Here is a much needed update fixing multiple regressions from the
> introduction of the IO API in 0.13. Among improvements is the much
> requested ability to restore the position in the stage view when staging
> diff hunks. Also noteworthy is the many optimizations of the screen
> updating to make it work better across slow links. Finally, beware that
> a handful of incompatibilities can cause problems.

I'm having a problem with tig taking 2 seconds to start up, which
seems to be related to the 'typo checking' feature of git. After
figuring out how to stop strace from helpfully saying
write(2, "WARNING: You called a Git program"..., 137) = 137
I got this (with -s 100):
[pid 29708] write(2, "WARNING: You called a Git program named 'git
config', which does not exist.\nContinuing under the assu"..., 137) =
137
[pid 29708] write(2, "in 2.0 seconds automatically...\n"..., 32) = 32

The output however also contains lots of git config strings, which is
confusing. Is tig running git config twice and failing one of the
times? (Running git config from the cmdline works fine).

-- 
Mikael Magnusson

Re: [ANNOUNCE] tig-0.14

[Peter Baumann]

First, let me say I like tig very much and apreciate your effort on
making it the best console based git viewer.

Now I have a little UI glitch, which might be solved already. If im
browsing through a lot of commits, I'd like to have a way to advance to
tne next/previous commit while also showing the diff like in the pictore
below. Right now I alwasy press 'q' to leave the diff view, select
commit C and press return to show me the diff. Wouldn't it be nice to
have a way to advance to the next diff without leaving the diff window?

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  |  commit A
  | >commit B
  |  commit C
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  | diff --git a/tig.c b/tig.c
  | index aec50bc..2dd0ef6 100644
  | --- a/tig.c
  | +++ b/tig.c
    ....

Greetings,
Peter

Re: [ANNOUNCE] tig-0.14

[Jeff King]

On Mon, Feb 09, 2009 at 11:07:50PM +0100, Peter Baumann wrote:

> Now I have a little UI glitch, which might be solved already. If im
> browsing through a lot of commits, I'd like to have a way to advance to
> tne next/previous commit while also showing the diff like in the pictore
> below. Right now I alwasy press 'q' to leave the diff view, select
> commit C and press return to show me the diff. Wouldn't it be nice to
> have a way to advance to the next diff without leaving the diff window?
> 
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   |  commit A
>   | >commit B
>   |  commit C
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   | diff --git a/tig.c b/tig.c
>   | index aec50bc..2dd0ef6 100644
>   | --- a/tig.c
>   | +++ b/tig.c

Don't the up and down arrows switch the commit (updating the diff pane
as appropriate), and PgUp/PgDown scroll the diff window (I don't know
the actual function names, but you should be able to even rebind these
in your tigrc if you want).

-Peff

Re: [ANNOUNCE] tig-0.14

[Peter Baumann]

On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:
> On Mon, Feb 09, 2009 at 11:07:50PM +0100, Peter Baumann wrote:
> 
> > Now I have a little UI glitch, which might be solved already. If im
> > browsing through a lot of commits, I'd like to have a way to advance to
> > tne next/previous commit while also showing the diff like in the pictore
> > below. Right now I alwasy press 'q' to leave the diff view, select
> > commit C and press return to show me the diff. Wouldn't it be nice to
> > have a way to advance to the next diff without leaving the diff window?
> > 
> >   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   |  commit A
> >   | >commit B
> >   |  commit C
> >   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   | diff --git a/tig.c b/tig.c
> >   | index aec50bc..2dd0ef6 100644
> >   | --- a/tig.c
> >   | +++ b/tig.c
> 
> Don't the up and down arrows switch the commit (updating the diff pane
> as appropriate), and PgUp/PgDown scroll the diff window (I don't know
> the actual function names, but you should be able to even rebind these
> in your tigrc if you want).
> 

Damn. I'm so used to the vi keybindings pressing j/k to move down/up
that I didn't check the cursor keys.

Sorry for the noise,
Peter

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Mon, Feb 9, 2009 at 23:30, Peter Baumann <waste.manager@gmx.de> wrote:
> On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:
>> Don't the up and down arrows switch the commit (updating the diff pane
>> as appropriate), and PgUp/PgDown scroll the diff window (I don't know
>> the actual function names, but you should be able to even rebind these
>> in your tigrc if you want).
>
> Damn. I'm so used to the vi keybindings pressing j/k to move down/up
> that I didn't check the cursor keys.

Well, initially tig worked similar to what you expected and a program
like slrn, where up/down (or j/k) moves between articles (commits) and
you have to press enter to actually show/load the commit in the diff
view. This mode might be more natural, and Jari has argued that it
would make tig (and it's many forks) more bearable to on Cygwin
running on an old PC.

Anyway, I would like to add support for something like this in the
future. But it will require some restructuring of the code to make the
link between the main view and it's diff view more natural.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jari Aalto]

Jonas Fonseca <fonseca@diku.dk> writes:

> On Mon, Feb 9, 2009 at 23:30, Peter Baumann <waste.manager@gmx.de> wrote:
>
>> On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:
>>> Don't the up and down arrows switch the commit (updating the diff pane
>>> as appropriate), and PgUp/PgDown scroll the diff window (I don't know
>>> the actual function names, but you should be able to even rebind these
>>> in your tigrc if you want).
>>
>> Damn. I'm so used to the vi keybindings pressing j/k to move down/up
>> that I didn't check the cursor keys.
>
> Well, initially tig worked similar to what you expected and a program
> like slrn, where up/down (or j/k) moves between articles (commits) and
> you have to press enter to actually show/load the commit in the diff
> view. This mode might be more natural, and Jari has argued that it
> would make tig (and it's many forks) more bearable to on Cygwin
> running on an old PC.

It also helps when you want to see only particular commit; you scroll to
correct location as ask display by pressing RET. If aut-update is in
effect, the other commits in between tie up the cursor movement,
especially if the history is long: tap, tap, tap .... and you'd have to
wait for all all screen to update line by line.

Idea: The auto-update feature could be even turned on/off with a
command-key . But an comand line option would do for me, as long as the
behaviot is configurable. It is slow under Cygwin, especially on
networked case, where Cygwin resides on remote disk, not the local one.

Jari

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> Release notes
> -------------
> Incompatibilities:

I notice that when I do the sequence...

*) open tig
*) hit <CR> to view first changeset
*) hit "j" to scroll one line

the green highlighting on the first line moves to the second, but the 
whitespace following the "commit 00000000000000" stays green. For 
example, if I do the sequence above in the tig repo, I'm left with

commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---
---This line (Refs:) has GREEN BG---

The "commit" has a black background.

Is that a bug? Or do I need to upgrade my ncurses?

If I hit <CR> a few more times (to move the screen) and then hit "j" 
more (to move the highlighted line), I get this same bug randomly on 
different lines.

Thanks --
Ted

P.S.

Again, thanks for this app.


-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Tue, Feb 10, 2009 at 14:29, Ted Pavlic <ted@tedpavlic.com> wrote:
> I notice that when I do the sequence...
>
> *) open tig
> *) hit <CR> to view first changeset
> *) hit "j" to scroll one line
>
> the green highlighting on the first line moves to the second, but the
> whitespace following the "commit 00000000000000" stays green. For example,
> if I do the sequence above in the tig repo, I'm left with
>
> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---
> ---This line (Refs:) has GREEN BG---
>
> The "commit" has a black background.
>
> Is that a bug? Or do I need to upgrade my ncurses?

Sounds like a bug. Probably from the drawing optimizations in tig-0.14.

No upgrade should be necessary. Could you give me some information
about what terminal application you are using. Also, have you added
any specific color settings to ~/.tigrc?

> If I hit <CR> a few more times (to move the screen) and then hit "j" more
> (to move the highlighted line), I get this same bug randomly on different
> lines.

This is a good hint. Does it happen a mostly when you hit "j" and it
causes the view to be scrolled down?

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Brian Gernhardt]

On Feb 10, 2009, at 1:29 PM, Jonas Fonseca wrote:

> On Tue, Feb 10, 2009 at 14:29, Ted Pavlic <ted@tedpavlic.com> wrote:
>> I notice that when I do the sequence...
>>
>> *) open tig
>> *) hit <CR> to view first changeset
>> *) hit "j" to scroll one line
>>
>> the green highlighting on the first line moves to the second, but the
>> whitespace following the "commit 00000000000000" stays green. For  
>> example,
>> if I do the sequence above in the tig repo, I'm left with
>>
>> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---
>> ---This line (Refs:) has GREEN BG---
>>
>> The "commit" has a black background.
>>
>> Is that a bug? Or do I need to upgrade my ncurses?
>
> Sounds like a bug. Probably from the drawing optimizations in  
> tig-0.14.

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 <Enter> to  
scroll down a line) causes the line to appear normally again, although  
movement from that point usually breaks it again.

> No upgrade should be necessary. Could you give me some information
> about what terminal application you are using. Also, have you added
> any specific color settings to ~/.tigrc?

OS 10.5.6's Terminal.app, with TERM=xterm-color
I have no .tigrc

~~ Brian

Re: [ANNOUNCE] tig-0.14

[Stefan Karpinski]

On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
<benji@silverinsanity.com> wrote:
>
> On Feb 10, 2009, at 1:29 PM, Jonas Fonseca wrote:
>
>> On Tue, Feb 10, 2009 at 14:29, Ted Pavlic <ted@tedpavlic.com> wrote:
>>>
>>> I notice that when I do the sequence...
>>>
>>> *) open tig
>>> *) hit <CR> to view first changeset
>>> *) hit "j" to scroll one line
>>>
>>> the green highlighting on the first line moves to the second, but the
>>> whitespace following the "commit 00000000000000" stays green. For example,
>>> if I do the sequence above in the tig repo, I'm left with
>>>
>>> commit e278600f599f60a2b98aeae6bfbb6ba92cf92d6f---GREEN BG HERE---
>>> ---This line (Refs:) has GREEN BG---
>>>
>>> The "commit" has a black background.
>>>
>>> Is that a bug? Or do I need to upgrade my ncurses?
>>
>> Sounds like a bug. Probably from the drawing optimizations in tig-0.14.
>
> 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 <Enter> to scroll down a line) causes the line to appear normally again, although movement from that point usually breaks it again.
>
>> No upgrade should be necessary. Could you give me some information
>> about what terminal application you are using. Also, have you added
>> any specific color settings to ~/.tigrc?
>
> OS 10.5.6's Terminal.app, with TERM=xterm-color
> I have no .tigrc

Ditto. Same bug. Completely vanilla tig setup. OS X Leopard,
tig-0.14-9-gd06137e, TERM=xterm-color.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
> <benji@silverinsanity.com> wrote:
>>
>> OS 10.5.6's Terminal.app, with TERM=xterm-color
>> I have no .tigrc
>
> Ditto. Same bug. Completely vanilla tig setup. OS X Leopard,
> tig-0.14-9-gd06137e, TERM=xterm-color.

Looks like there might be a pattern and I might have an excuse to go
knock on the door of one of my "Mac" friends. ;) However, first I
would kindly ask if one of you have time to test the attached patch.

Thanks both of you and sorry for the inconvenience.

-- 
Jonas Fonseca

[-- Attachment #2: 0001-Fix-regression-where-a-line-was-not-cleared-when-not.patch --]
[-- Type: text/x-diff, Size: 828 bytes --]

From 3670b9f20c49c46c6418d7dbcce8265b2fe8a853 Mon Sep 17 00:00:00 2001
From: Jonas Fonseca <fonseca@diku.dk>
Date: Tue, 10 Feb 2009 21:33:18 +0100
Subject: [PATCH] Fix regression where a line was not cleared when not selected anymore

Introduced in 273c28df2aa5cc0d122b1a0f3c0014a56ab8c392 (Tree view: make
drawing more smooth by using the dirty flag).
---
 tig.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tig.c b/tig.c
index 7072094..02f4bd8 100644
--- a/tig.c
+++ b/tig.c
@@ -2055,7 +2055,7 @@ draw_view_line(struct view *view, unsigned int lineno)
 	line = &view->line[view->offset + lineno];
 
 	wmove(view->win, lineno, 0);
-	if (line->cleareol)
+	if (line->cleareol || (line->selected && !selected))
 		wclrtoeol(view->win);
 	view->col = 0;
 	view->curline = line;
-- 
1.6.1.1.347.g3f81d

Re: [ANNOUNCE] tig-0.14

[Brian Gernhardt]

On Feb 10, 2009, at 3:41 PM, Jonas Fonseca wrote:

> On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski
> <stefan.karpinski@gmail.com> wrote:
>> On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
>> <benji@silverinsanity.com> wrote:
>>>
>>> OS 10.5.6's Terminal.app, with TERM=xterm-color
>>> I have no .tigrc
>>
>> Ditto. Same bug. Completely vanilla tig setup. OS X Leopard,
>> tig-0.14-9-gd06137e, TERM=xterm-color.
>
> Looks like there might be a pattern and I might have an excuse to go
> knock on the door of one of my "Mac" friends. ;) However, first I
> would kindly ask if one of you have time to test the attached patch.

That fixes half the problem.  It no longer leaves a highlight on the  
wrong line, but the newly selected line does not highlight the empty  
space at the end of the line.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt <benji@silverinsanity.com> wrote:
> That fixes half the problem.  It no longer leaves a highlight on the wrong
> line, but the newly selected line does not highlight the empty space at the
> end of the line.

I believe the empty space is the cursor, but I am not sure. At least
tig-0.14 should be more consistent regarding the cursor position,
which is now always placed at the end of the selected line, except
when the input prompt is in use.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Brian Gernhardt]

On Feb 10, 2009, at 4:13 PM, Jonas Fonseca wrote:

> On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt <benji@silverinsanity.com 
> > wrote:
>> That fixes half the problem.  It no longer leaves a highlight on  
>> the wrong
>> line, but the newly selected line does not highlight the empty  
>> space at the
>> end of the line.
>
> I believe the empty space is the cursor, but I am not sure. At least
> tig-0.14 should be more consistent regarding the cursor position,
> which is now always placed at the end of the selected line, except
> when the input prompt is in use.

That's not what I'm referring to.  I mean that if there's a line that  
does not take the entire width of the screen, the space from the end  
of the text to the end of the screen is black.

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> That fixes half the problem.  It no longer leaves a highlight on the
> wrong line, but the newly selected line does not highlight the empty
> space at the end of the line.

I haven't tried the patch yet, but I can tell you that (on my system) 
the other "half" of the problem is there before the patch.

That is, the trailing whitespace on a new line goes without highlight. I 
was under the (wrong?) impression that this was desired and that the 
whitespace highlighting was a bug. No?

(in fact, it might be useful if the trailing "screen space" is *not* 
highlighted. That makes it easy to X-ray trailing whitespace buried in 
the changeset)

--Ted

-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Wed, Feb 11, 2009 at 15:06, Ted Pavlic <ted@tedpavlic.com> wrote:
> That is, the trailing whitespace on a new line goes without highlight. I was
> under the (wrong?) impression that this was desired and that the whitespace
> highlighting was a bug. No?

The basic idea of the "cursor line" is that the whole line including
any trailing space is highlighted.

> (in fact, it might be useful if the trailing "screen space" is *not*
> highlighted. That makes it easy to X-ray trailing whitespace buried in the
> changeset)

Well, I don't know if tig is the right tool for detecting that.

I have noted your comment about different terminals being in play. A
fact that is rather discouraging. Will try to get some time in front
of OSX to look more into it. I have an idea for a temporary fix, which
I would like you to test when it is ready.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> Looks like there might be a pattern and I might have an excuse to go
> knock on the door of one of my "Mac" friends. ;) However, first I
> would kindly ask if one of you have time to test the attached patch.

It fixes it for me.

As noted, the highlight in the changesets does not go to the end of the 
line (where there is a cursor displayed) as it did before. I can see how 
some people might view this as a feature (i.e., having the whole line 
highlighted).

--Ted


-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> Looks like there might be a pattern and I might have an excuse to go
> knock on the door of one of my "Mac" friends. ;) However, first I
> would kindly ask if one of you have time to test the attached patch.

Any verdict on this patch (it WFM)? I notice tig is still unpatched to 
fix this problem.

Thanks --
Ted

-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On Fri, Feb 20, 2009 at 18:24, Ted Pavlic <ted@tedpavlic.com> wrote:
>> Looks like there might be a pattern and I might have an excuse to go
>> knock on the door of one of my "Mac" friends. ;) However, first I
>> would kindly ask if one of you have time to test the attached patch.
>
> Any verdict on this patch (it WFM)? I notice tig is still unpatched to fix
> this problem.

I didn't look more into it. Maybe you can try the attached patch for me.

-- 
Jonas Fonseca

[-- Attachment #2: 0001-Fix-regression-where-a-line-was-not-cleared-when-not.patch --]
[-- Type: text/x-diff, Size: 1566 bytes --]

From 270e894b59cac1baa3ee2cb4c12f320efb3fea30 Mon Sep 17 00:00:00 2001
From: Jonas Fonseca <fonseca@diku.dk>
Date: Tue, 10 Feb 2009 21:33:18 +0100
Subject: [PATCH] Fix regression where a line was not cleared when not selected anymore

Introduced in 273c28df2aa5cc0d122b1a0f3c0014a56ab8c392 (Tree view: make
drawing more smooth by using the dirty flag).
---
 tig.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tig.c b/tig.c
index 2a3ab3a..fbbd1cc 100644
--- a/tig.c
+++ b/tig.c
@@ -2073,6 +2073,7 @@ draw_view_line(struct view *view, unsigned int lineno)
 {
 	struct line *line;
 	bool selected = (view->offset + lineno == view->lineno);
+	bool cleareol;
 
 	assert(view_is_displayed(view));
 
@@ -2080,10 +2081,9 @@ draw_view_line(struct view *view, unsigned int lineno)
 		return FALSE;
 
 	line = &view->line[view->offset + lineno];
+	cleareol = line->cleareol || (line->selected && !selected);
 
 	wmove(view->win, lineno, 0);
-	if (line->cleareol)
-		wclrtoeol(view->win);
 	view->col = 0;
 	view->curline = line;
 	view->curtype = LINE_NONE;
@@ -2094,6 +2094,11 @@ draw_view_line(struct view *view, unsigned int lineno)
 		set_view_attr(view, LINE_CURSOR);
 		line->selected = TRUE;
 		view->ops->select(view, line);
+	} else if (cleareol) {
+		/* FIXME: It is not strictly correct to only clear to
+		 * the line end for non-selected lines. However, no view
+		 * currently requires clearing for the first line. */
+		wclrtoeol(view->win);
 	}
 
 	return view->ops->draw(view, line, lineno);
-- 
1.6.2.rc1.209.gfe624.dirty

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

Both patches (the new and the old) seem to fix the original problem.

However, I now notice that both patches introduces a new problem. From 
the tig repo (with no .tigrc), I run tig to view the single-line 
changelog. I then hit "Enter" to view the first commit (which is your 
fix). I then hit "j" and "k" to scroll through it.

*Sometimes* the entire line gets highlighted with a green background, 
and *sometimes* it doesn't (i.e., sometimes the green background doesn't 
highlight the whitespace between the end of the line and the right-hand 
side of the terminal, and sometimes it does). That is, if I hold down 
"j" to scroll through the commit, and then hold down "k" to scroll back, 
lines that were highlighted all the way from left to right on the way 
down are only highlighted part of the way on the way up.

--Ted

On 2/20/09 1:34 PM, Jonas Fonseca wrote:
> On Fri, Feb 20, 2009 at 18:24, Ted Pavlic<ted@tedpavlic.com>  wrote:
>>> Looks like there might be a pattern and I might have an excuse to go
>>> knock on the door of one of my "Mac" friends. ;) However, first I
>>> would kindly ask if one of you have time to test the attached patch.
>> Any verdict on this patch (it WFM)? I notice tig is still unpatched to fix
>> this problem.
>
> I didn't look more into it. Maybe you can try the attached patch for me.
>

-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 20, 2009 at 21:36, Ted Pavlic <ted@tedpavlic.com> wrote:
> Both patches (the new and the old) seem to fix the original problem.
>
> However, I now notice that both patches introduces a new problem. From the
> tig repo (with no .tigrc), I run tig to view the single-line changelog. I
> then hit "Enter" to view the first commit (which is your fix). I then hit
> "j" and "k" to scroll through it.

Hmm. I probably won't be able to look at this before sometime in April. Sorry.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Fri, Feb 20, 2009 at 21:36, Ted Pavlic <ted@tedpavlic.com> wrote:
> Both patches (the new and the old) seem to fix the original problem.
>
> However, I now notice that both patches introduces a new problem.

I finally found a way to reproduce and bisect this today on a linux
box with ncurses-5.5 installed. To double check can you please try
this third version?

-- 
Jonas Fonseca

[-- Attachment #2: 0001-Fix-regression-where-a-line-was-not-cleared-when-not.patch --]
[-- Type: text/x-diff, Size: 1758 bytes --]

From 5458881439b362b6d729500bc7d67bd100cdd8b4 Mon Sep 17 00:00:00 2001
From: Jonas Fonseca <fonseca@diku.dk>
Date: Tue, 10 Feb 2009 21:33:18 +0100
Subject: [PATCH] Fix regression where a line was not cleared when not selected anymore

Introduced in 792d0e0931fb8785135a6b5d250a570a597c7324 which tried to
eliminated unneeded calls to redrawwin(). However, for older ncurses
versions (5.5) this caused problems. To fix this explicitly mark newly
selected lines using wtouchln(), so they are properly redrawn.
---
 tig.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tig.c b/tig.c
index 2a3ab3a..df2b4f6 100644
--- a/tig.c
+++ b/tig.c
@@ -2073,6 +2073,7 @@ draw_view_line(struct view *view, unsigned int lineno)
 {
 	struct line *line;
 	bool selected = (view->offset + lineno == view->lineno);
+	bool cleareol;
 
 	assert(view_is_displayed(view));
 
@@ -2080,10 +2081,9 @@ draw_view_line(struct view *view, unsigned int lineno)
 		return FALSE;
 
 	line = &view->line[view->offset + lineno];
+	cleareol = line->cleareol || (line->selected && !selected);
 
 	wmove(view->win, lineno, 0);
-	if (line->cleareol)
-		wclrtoeol(view->win);
 	view->col = 0;
 	view->curline = line;
 	view->curtype = LINE_NONE;
@@ -2094,6 +2094,12 @@ draw_view_line(struct view *view, unsigned int lineno)
 		set_view_attr(view, LINE_CURSOR);
 		line->selected = TRUE;
 		view->ops->select(view, line);
+		touchline(view->win, lineno, 1);
+	} else if (cleareol) {
+		/* FIXME: It is not strictly correct to only clear to
+		 * the line end for non-selected lines. However, no view
+		 * currently requires clearing for the first line. */
+		wclrtoeol(view->win);
 	}
 
 	return view->ops->draw(view, line, lineno);
-- 
1.6.2.rc1.209.gfe624.dirty

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> No upgrade should be necessary. Could you give me some information
> about what terminal application you are using. Also, have you added
> any specific color settings to ~/.tigrc?

OS X 10.4.11
iTerm 0.9.6.1201
TERM=xterm-color

I have no ~/.tigrc

>> If I hit<CR>  a few more times (to move the screen) and then hit "j" more
>> (to move the highlighted line), I get this same bug randomly on different
>> lines.
>
> This is a good hint. Does it happen a mostly when you hit "j" and it
> causes the view to be scrolled down?

The problem only occurs with "j" and "k" when viewing multi-line 
displays. I do /not/ see the problem when viewing the one-line changeset 
history. It only causes a problem when I view the multi-line displays 
(e.g., when actually viewing a changeset).

For example, in git.git, if I "tig" and then scroll through the 
changesets, I don't see the problem. If I <CR> on a changeset so that it 
opens in the bottom half of the screen, I see the problem when I start 
"j" and "k"'ing there.

Thanks --
Ted



-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

>> No upgrade should be necessary. Could you give me some information
>> about what terminal application you are using. Also, have you added
>> any specific color settings to ~/.tigrc?
>
> OS X 10.4.11
> iTerm 0.9.6.1201
> TERM=xterm-color
>
> I have no ~/.tigrc

Perhaps not surprisingly, when I ssh into a Linux machine and run tig, I 
have the same problem.

That is, "tig" is being run on the Linux machine, but the terminal is on 
my Mac.

It might be interesting that although several people with this problem 
use a Mac, we do not use the same terminal program.

--Ted

-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Ted Pavlic]

> What is tig?


*) Is there any way for "tig" to emulate "less -R"?

That is, if an output is already colorized, can tig just pass through 
the ANSI?


*) When doing "git diff|tig" when there directory is clean, tig should 
probably exit immediately, right?


*) Also, is there a way to configure "tig" to colorize and *exit* if the 
piped text doesn't fill a page?


(in other words, I'd like "tig" to be able to replace my current "less 
-FRX" pager)

Thanks --
Ted

-- 
Ted Pavlic <ted@tedpavlic.com>

   Please visit my ALS association page:
         http://web.alsa.org/goto/tedpavlic
   My family appreciates your support in the fight to defeat ALS.

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Wed, Feb 11, 2009 at 18:47, Ted Pavlic <ted@tedpavlic.com> wrote:
> *) Is there any way for "tig" to emulate "less -R"?
>
> That is, if an output is already colorized, can tig just pass through the
> ANSI?

Tig is heavily tied to ncurses and as far as I know ncurses does not
support this. So it would require tig to parse the ANSI terminal codes
into some representation from which the equivalent calls to the
ncurses API is made.

> *) When doing "git diff|tig" when there directory is clean, tig should
> probably exit immediately, right?

Yes, good idea. The blame and main view currently does this too. Will
look into it.

> *) Also, is there a way to configure "tig" to colorize and *exit* if the
> piped text doesn't fill a page?

No. However, this I have actually considered to support at some point,
since it would make it possible to test the rendering. Again, this is
not something ncurses supports as far as I know, so would require some
kind ofl "ANSI" code emitter.

> (in other words, I'd like "tig" to be able to replace my current "less -FRX"
> pager)

It will probably take a some time to get there, but I am open to
moving in this direction.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Thu, 05 Feb 2009 21:44:36 +0100, Jonas Fonseca <fonseca@diku.dk> wrote:

> Here is a much needed update fixing multiple regressions from the
> introduction of the IO API in 0.13.

Thank you for this _really_ nice program.

One thing came to my mind. When I use 'S' and then 'u' to stage/unstage  
files, it would be nice if I could press a key(maybe 'C') to fire up my  
$EDITOR, enter my commit message, let tig do the commit and find myself  
back into the updated status view. Does this sound reasonable?

Viele Grüße,

     Tilo

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
> One thing came to my mind. When I use 'S' and then 'u' to stage/unstage
> files, it would be nice if I could press a key(maybe 'C') to fire up my
> $EDITOR, enter my commit message, let tig do the commit and find myself back
> into the updated status view. Does this sound reasonable?

Sure, you can achieve this very easily. For example, I have the
following bindings in my ~/.tigrc:

 bind generic + !git commit --amend
 bind generic . !git commit

With tig-0.14, you can also put bindings in your ~/.gitconfig or the
project specific .git/config file using:

 [tig "bind"]
    generic = C !git commit
    generic = w !firefox http://repo.or.cz/w/tig.git?h=%(commit)

The last one uses "browsing state variables". There is more
information about those in tigrc(5)[1]

[1] http://jonas.nitro.dk/tig/tigrc.5.html#_actions

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Thu, 12 Feb 2009 23:24:56 +0100, Jonas Fonseca  
<jonas.fonseca@gmail.com> wrote:

> On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
>> One thing came to my mind. When I use 'S' and then 'u' to stage/unstage
>> files, it would be nice if I could press a key(maybe 'C') to fire up my
>> $EDITOR, enter my commit message, let tig do the commit and find myself  
>> back
>> into the updated status view. Does this sound reasonable?
>
> Sure, you can achieve this very easily. For example, I have the
> following bindings in my ~/.tigrc:
>
>  bind generic + !git commit --amend
>  bind generic . !git commit
>
> With tig-0.14, you can also put bindings in your ~/.gitconfig or the
> project specific .git/config file using:
>
>  [tig "bind"]
>     generic = C !git commit
>     generic = w !firefox http://repo.or.cz/w/tig.git?h=%(commit)
>
> The last one uses "browsing state variables". There is more
> information about those in tigrc(5)[1]

Wow, that flexibility is really impressive!

Then I have another question: Did you ever thought of a branch view, where  
you can see, create, delete and merge the different branches which are in  
a git project.

Best regards,
(oops, I forgot to change this to the lists language in my previous post)

     Tilo

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
> Then I have another question: Did you ever thought of a branch view, where
> you can see, create, delete and merge the different branches which are in a
> git project.

I have thought about it. The question is if a separate view is
necessary or if the main view would do. For example, I sometimes use
gitk when I need to rename branches or prepare for rebasing a
patchset. One idea I would like to explore is to provide a compressed
version of the main view, where "intermediate" commits are hidden,
this way you could easily get a view of the relationship between
branches.

The simplest thing to make it easier to experiment with new features
would probably be to introduce a new external command specifier:
%(prompt:<msg>), possibly with some regex for validation. Then you
could add in your ~/.tigrc:

bind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Sitaram Chamarty]

On 2009-02-15, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> patchset. One idea I would like to explore is to provide a compressed
> version of the main view, where "intermediate" commits are hidden,
> this way you could easily get a view of the relationship between
> branches.

like 'gitk --simplify-by-decoration --all'?

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 2009-02-15, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>> patchset. One idea I would like to explore is to provide a compressed
>> version of the main view, where "intermediate" commits are hidden,
>> this way you could easily get a view of the relationship between
>> branches.
>
> like 'gitk --simplify-by-decoration --all'?

Great, didn't know about this option. If only tig could show the
revision graph properly ... ;)

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Sitaram Chamarty]

On 2009-02-16, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> On 2009-02-15, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>>> patchset. One idea I would like to explore is to provide a compressed
>>> version of the main view, where "intermediate" commits are hidden,
>>> this way you could easily get a view of the relationship between
>>> branches.
>>
>> like 'gitk --simplify-by-decoration --all'?
>
> Great, didn't know about this option. If only tig could show the

'git log' acquired it recently, or more precisely git
rev-list did, I think.

> revision graph properly ... ;)

Yes I was going to ask about that, having been confused by
the graph once in a while.  You may want to consider using a
few other characters than the 4 you currently do (if indeed
that is the problem).

I'm interested in this too, and I do sometimes have complex
branch relationships in my work.  I'm no longer much of a C
programmer but I can certainly help test.

Re: [ANNOUNCE] tig-0.14

[Thomas Adam]

2009/2/16 Sitaram Chamarty <sitaramc@gmail.com>:
> Yes I was going to ask about that, having been confused by
> the graph once in a while.  You may want to consider using a
> few other characters than the 4 you currently do (if indeed
> that is the problem).
>
> I'm interested in this too, and I do sometimes have complex
> branch relationships in my work.  I'm no longer much of a C
> programmer but I can certainly help test.

I started work on this last year, but it got pushed further and
further down my todo list.   Basically, there's extended characters
defined as part of ncurses for just this sort of "drawing" operation.

-- Thomas Adam

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Mon, Feb 16, 2009 at 16:25, Thomas Adam <thomas.adam22@gmail.com> wrote:
> 2009/2/16 Sitaram Chamarty <sitaramc@gmail.com>:
>> Yes I was going to ask about that, having been confused by
>> the graph once in a while.  You may want to consider using a
>> few other characters than the 4 you currently do (if indeed
>> that is the problem).
>
> I started work on this last year, but it got pushed further and
> further down my todo list.   Basically, there's extended characters
> defined as part of ncurses for just this sort of "drawing" operation.

Yes, I think we need to go for something squarish like qgit and giggle.

With this rewrite I it could also be nice to allow the graph rendering
to be more incremental by changing the commit struct to point to the
parent commits. This will also enable support for moving the cursor to
the parent commit in the main view and calculate information like the
Follows/Preceeds in gitk.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Marco Costalba]

On Mon, Feb 16, 2009 at 20:52, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>
> Yes, I think we need to go for something squarish like qgit and giggle.
>

Thanks to an anonymous contributor graphs in qgit are no squarish anymore !!!

Pull or download from qgit public repo to enjoy the qgit graph cool
new look! :-)

git://git.kernel.org/pub/scm/qgit/qgit4.git

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca  
<jonas.fonseca@gmail.com> wrote:

> On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
>> Then I have another question: Did you ever thought of a branch view,  
>> where
>> you can see, create, delete and merge the different branches which are  
>> in a
>> git project.
>
> I have thought about it. The question is if a separate view is
> necessary or if the main view would do. For example, I sometimes use
> gitk when I need to rename branches or prepare for rebasing a
> patchset. One idea I would like to explore is to provide a compressed
> version of the main view, where "intermediate" commits are hidden,
> this way you could easily get a view of the relationship between
> branches.

I'm not sure if I understood it correctly. Do you mean, only commits are  
shown, which are heads of some branch? If so, what if more than one head  
points to the same commit?

The branch thing came into my mind, because it's the only thing which  
keeps me from using tig exclusively. I sometimes switch to git-gui to do  
the branch handling. Since I really like those "one key press is one  
command" kind of programs like tig (or mc, aptitude, mocp, ...), it would  
be really nice to have the branches in tig too. The nice thing of programs  
like tig is (matter of taste of course), that once you get used to the  
keys, you don't have to think about commands anymore, you just do them.

I think I would prefer a branch view, because then one could also have a  
branch-view keymap with specialized commands. One possibility would be  
(just as example):

The view shows something like this (here an example from the tig git  
repository)

   master
* my_feature_bar
X my_feature_foo
   origin/HEAD
   origin/master
   origin/release

The current branch is marked by '*'. Now let's assume, I am with my cursor  
on the line with the 'X', I could think of the keys

d (d)elete the X-marked branch, given is has already been merged into  
another branch
n create a (n)ew branch, based on the X-marked branch,
   ask for the new name and (maybe checkout the new branch)
c (c)heckout the branch
r (r)ename the branch
R (r)eset branch
...

I don't think it's necessary to reproduce all the nice options git-gui  
has, but if there would be a branch view with the most used 5 commands /  
work steps, it would cover 95% of the daily "branch work" which is needed.  
And it would be simply awesome, if we could do this without leaving tig,  
but instead use this very nice and fast "one key, one command" also for  
the branches. Of course the more complicated and special cases can be  
always handled by tig by pressing ':' and entering a git command.

> The simplest thing to make it easier to experiment with new features
> would probably be to introduce a new external command specifier:
> %(prompt:<msg>), possibly with some regex for validation. Then you
> could add in your ~/.tigrc:
>
> bind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)

Ahh, ok, so tig would issue a prompt and ask me for the name?


Thanks for the great program!


BTW, is the git list the right list to discuss bugs / patches for tig?

Best regards,

     Tilo

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Mon, Feb 16, 2009 at 22:12, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
> On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca <jonas.fonseca@gmail.com>
> wrote:
>
>> I have thought about it. The question is if a separate view is
>> necessary or if the main view would do.
>
> I'm not sure if I understood it correctly. Do you mean, only commits are
> shown, which are heads of some branch? If so, what if more than one head
> points to the same commit?

True, it is not very intuitive with more than one branch perhaps.
However, I still think there is some overlap between a branch view,
the main view and possible also the status view. From the status view
you might want to create a new branch based on changes, and in the
main view you might want to create a branch to help backport a bugfix.

> I think I would prefer a branch view, because then one could also have a
> branch-view keymap with specialized commands. One possibility would be (just
> as example):

Maybe it is best to keep it simple and focus on your idea first and
make tig at least aware of branches. And yes, it makes sense with an
new keymap.

> The view shows something like this (here an example from the tig git
> repository)
>
>  master
> * my_feature_bar
> X my_feature_foo
>  origin/HEAD
>  origin/master
>  origin/release

OK, I have added the begining structure for a branch view, bound to
'H' by default. It does not support any actions besides refreshing and
viewing the branch history. So there is still some work to achieve the
easy access to branch commands.

>> bind main A !git branch %(prompt:^wip/[a-z-]+$:Name) %(commit)
>
> Ahh, ok, so tig would issue a prompt and ask me for the name?

Yeah, I don't know if it will be useful.

> BTW, is the git list the right list to discuss bugs / patches for tig?

Yes please.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca  
<jonas.fonseca@gmail.com> wrote:

[...]
> OK, I have added the begining structure for a branch view, bound to
> 'H' by default. It does not support any actions besides refreshing and
> viewing the branch history. So there is still some work to achieve the
> easy access to branch commands.

That's really nice!

>> BTW, is the git list the right list to discuss bugs / patches for tig?
>
> Yes please.

Ok, here we go ;-).

I can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555
like this, using the tig repo itself:

- Start ./tig --all
- Enter the new branch view pressing 'H'
- Add a new branch foo using git checkout -b foo on some
   console or in tig using ':checkout -b foo'
- Press F5 in the branch view to reload
- Move cursor on the new branch foo
- Press ENTER

Then I get a SIGSEGV in line

6150                            if (ref->head)

(gdb) print *ref
Cannot access memory at address 0x2d676974

#0  0x08056427 in main_draw (view=0x8060500, line=0x9b61638, lineno=0) at  
tig.c:6150
#1  0x0804d19d in draw_view_line (view=0x8060500, lineno=0) at tig.c:2111
#2  0x0804d269 in redraw_view_from (view=0x8060500, lineno=0) at tig.c:2141
#3  0x0804d2bf in redraw_view (view=0x8060500) at tig.c:2152
#4  0x0804f70b in open_view (prev=0x8062fa8, request=REQ_VIEW_MAIN,  
flags=OPEN_SPLIT) at tig.c:3055
#5  0x08053241 in branch_request (view=0x8062fa8, request=REQ_ENTER,  
line=0x9b6b038) at tig.c:4783
#6  0x0804f9df in view_driver (view=0x8062fa8, request=REQ_ENTER) at  
tig.c:3142
#7  0x080594a3 in main (argc=Cannot access memory at address 0x3

I tried to track this down, but was not successful yet (having seen tig.c  
the first time today). I looked in get_refs and read_ref, but couldn't  
nail it down up to now. It feels, as if the refresh does find and update  
the new branch foo, but the corresponding commit->refs are not properly  
updated (just guessing).

Best regards & thank you for tig!

     Tilo

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
> On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca <jonas.fonseca@gmail.com>
> wrote:
> Ok, here we go ;-).
>
> I can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555
> like this, using the tig repo itself:

Should be fixed already in commit
129cf793c915ac00dac86c561c25099cd3cd4be0 (Fix reloading of references
to not cause access to freed memory).

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Sat, 21 Feb 2009 18:41:51 +0100, Jonas Fonseca  
<jonas.fonseca@gmail.com> wrote:

> On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz <tilo@tilo-schwarz.de> wrote:
>> On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca  
>> <jonas.fonseca@gmail.com>
>> wrote:
>> Ok, here we go ;-).
>>
>> I can trigger a SIGSEGV in da8b99da8f4dc5512c23154ec6c0aa7d3c313555
>> like this, using the tig repo itself:
>
> Should be fixed already in commit
> 129cf793c915ac00dac86c561c25099cd3cd4be0 (Fix reloading of references
> to not cause access to freed memory).

That was quick! I can't trigger the SIGSEGV anymore.

Regards,

     Tilo

Re: [ANNOUNCE] tig-0.14

[Tilo Schwarz]

On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca  
<jonas.fonseca@gmail.com> wrote:

> I have thought about it. The question is if a separate view is
> necessary or if the main view would do. For example, I sometimes use
> gitk when I need to rename branches or prepare for rebasing a
> patchset. One idea I would like to explore is to provide a compressed
> version of the main view, where "intermediate" commits are hidden,
> this way you could easily get a view of the relationship between
> branches.

After seeing

./gitk --simplify-by-decoration --all

for the first time today I think now I know better what you mean.  
Nevertheless, compared to a separate branch-view, there are two points:
- How to I select a branch, if there is more than one branch on one commit  
(and thus on one line)
- Would it still be possible to create nice and fast one (or two) key  
commands for the most used every-day branch commands.

Best regards,

     Tilo

Re: [ANNOUNCE] tig-0.14

[bill lam]

On Thu, 12 Feb 2009, Jonas Fonseca wrote:
> The last one uses "browsing state variables". There is more
> information about those in tigrc(5)[1]

I can see that scroll-left/right only do it for one column, that is
not very convenient, Will it be possible to scroll for 10 columns or
half screen?

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩260 李益  江南曲
    嫁得瞿塘賈  朝朝誤妾期  早知潮有信  嫁與弄潮兒

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

On Fri, Feb 13, 2009 at 03:31, bill lam <cbill.lam@gmail.com> wrote:
> I can see that scroll-left/right only do it for one column, that is
> not very convenient, Will it be possible to scroll for 10 columns or
> half screen?

Certainly, the one column thing was good for testing but agreeable not
very usable so I have made the behavior of horizontal scrolling
configurable. You can either set the 'horizontal-scroll' variable to
the number of columns or the percentage of the view width you want to
scroll. Defaults to scrolling 50% of the view width.

-- 
Jonas Fonseca

Re: [ANNOUNCE] tig-0.14

[bill lam]

On Sat, 14 Feb 2009, Jonas Fonseca wrote:
> Certainly, the one column thing was good for testing but agreeable not
> very usable so I have made the behavior of horizontal scrolling
> configurable. You can either set the 'horizontal-scroll' variable to
> the number of columns or the percentage of the view width you want to
> scroll. Defaults to scrolling 50% of the view width.

Thanks.  I tested and found that there might be a bug.  For some lines
(>100 columns) it stoped scrolling even there are text there, instead
it displayed a ~ sign at the edge.  Even I set in the .tigrc

set horizontal-scroll = 1

It still did not works.

Also, when editing in the command mode, the back-space and left arrow
keys do not move cursor.  It can only use ctrl-h to delete the last
character.  Apparently it did not use readline and was impossible to
recall history using up-arrow key.  It should be perfect if it use
readline and can also work in vi keybinding mode.

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩209 李商隱  錦瑟
    錦瑟無端五十絃  一絃一柱思華年  莊生曉夢迷蝴蝶  望帝春心託杜鵑
    滄海月明珠有淚  藍田日暖玉生煙  此情可待成追憶  只是當時已惘然

Re: [ANNOUNCE] tig-0.14

[Jonas Fonseca]

2009/2/14 bill lam <cbill.lam@gmail.com>:
> On Sat, 14 Feb 2009, Jonas Fonseca wrote:
>> [About horizontal scrolling]
>
> Thanks.  I tested and found that there might be a bug.  For some lines
> (>100 columns) it stoped scrolling even there are text there, instead
> it displayed a ~ sign at the edge.

This should have been addressed in tig-0.14.1.

> Also, when editing in the command mode, the back-space and left arrow
> keys do not move cursor.  It can only use ctrl-h to delete the last
> character.  Apparently it did not use readline and was impossible to
> recall history using up-arrow key.  It should be perfect if it use
> readline and can also work in vi keybinding mode.

According to the ncurses FAQ, it is not straight forward to use
readline. Of course you could call out, but then views loading in the
background would stop working. I know this part of tig hasn't received
a lot of work, and it has been noted in the TODO. I would be happy to
give you some pointers if you are interested in looking into this
yourself.

-- 
Jonas Fonseca