[ANNOUNCE] tig-0.14

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

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 杜甫  天末懷李白
    涼風起天末  君子意如何  鴻雁幾時到  江湖秋水多
    文章憎命達  魑魅喜人過  應共冤魂語  投詩贈汨羅

2009/2/6 bill lam [off-list ref]:

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

On 2009-02-06, Jonas Fonseca [off-list ref] 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!

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

On Fri, Feb 6, 2009 at 20:15, Jeff King [off-list ref] wrote:

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

quoted

 - 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

Jonas Fonseca [off-list ref] writes:

On Fri, Feb 6, 2009 at 20:15, Jeff King [off-list ref] wrote:

quoted

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

quoted

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

quoted

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

2009/2/5 Jonas Fonseca [off-list ref]:

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

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

quoted

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

On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty [off-list ref] wrote:

On 2009-02-06, Jonas Fonseca [off-list ref] wrote:

quoted

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

On Fri, Feb 6, 2009 at 23:53, Jakub Narebski [off-list ref] wrote:

Jonas Fonseca [off-list ref] writes:

quoted

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

On Sat, Feb 7, 2009 at 08:10, Jeff King [off-list ref] 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

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

On Sat, Feb 7, 2009 at 08:10, Jeff King [off-list ref] wrote:

quoted

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 <redacted>
---
 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

On Sun, Feb 8, 2009 at 12:00, Jeff King [off-list ref] 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

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

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

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:

quoted

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

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 [off-list ref]

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

On Tue, Feb 10, 2009 at 14:29, Ted Pavlic [off-list ref] 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

On Mon, Feb 9, 2009 at 23:30, Peter Baumann [off-list ref] wrote:

On Mon, Feb 09, 2009 at 05:22:36PM -0500, Jeff King wrote:

quoted

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

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

On Tue, Feb 10, 2009 at 14:29, Ted Pavlic [off-list ref] wrote:

quoted

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

On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
[off-list ref] wrote:

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

quoted

On Tue, Feb 10, 2009 at 14:29, Ted Pavlic [off-list ref] wrote:

quoted

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.

quoted

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.

On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski
[off-list ref] wrote:

On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
[off-list ref] wrote:

quoted

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

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

On Tue, Feb 10, 2009 at 20:29, Stefan Karpinski
[off-list ref] wrote:

quoted

On Tue, Feb 10, 2009 at 11:07 AM, Brian Gernhardt
[off-list ref] wrote:

quoted

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.

On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt [off-list ref] 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

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

On Tue, Feb 10, 2009 at 21:49, Brian Gernhardt <benji@silverinsanity.com 

quoted

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.

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

quoted

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 [off-list ref]

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

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 [off-list ref]

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

quoted

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 [off-list ref]

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

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 [off-list ref]

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

On 2009-02-08, Jonas Fonseca [off-list ref] wrote:

On Fri, Feb 6, 2009 at 16:25, Sitaram Chamarty [off-list ref] wrote:

quoted

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.

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 [off-list ref]

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

On Wed, Feb 11, 2009 at 18:47, Ted Pavlic [off-list ref] 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

On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty [off-list ref] 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

On Wed, Feb 11, 2009 at 15:06, Ted Pavlic [off-list ref] 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

On 2009-02-12, Jonas Fonseca [off-list ref] wrote:

On Wed, Feb 11, 2009 at 17:05, Sitaram Chamarty [off-list ref] wrote:

quoted

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

On Thu, 05 Feb 2009 21:44:36 +0100, Jonas Fonseca [off-list ref] 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

On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz [off-list ref] 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

On Thu, 12 Feb 2009 23:24:56 +0100, Jonas Fonseca  
[off-list ref] wrote:

On Thu, Feb 12, 2009 at 22:48, Tilo Schwarz [off-list ref] wrote:

quoted

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

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 李益  江南曲
    嫁得瞿塘賈  朝朝誤妾期  早知潮有信  嫁與弄潮兒

On Fri, Feb 13, 2009 at 03:31, bill lam [off-list ref] 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

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 李商隱  錦瑟
    錦瑟無端五十絃  一絃一柱思華年  莊生曉夢迷蝴蝶  望帝春心託杜鵑
    滄海月明珠有淚  藍田日暖玉生煙  此情可待成追憶  只是當時已惘然

2009/2/14 bill lam [off-list ref]:

On Sat, 14 Feb 2009, Jonas Fonseca wrote:

quoted

[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

On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz [off-list ref] 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

On 2009-02-15, Jonas Fonseca [off-list ref] 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'?

On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty [off-list ref] wrote:

On 2009-02-15, Jonas Fonseca [off-list ref] wrote:

quoted

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

On 2009-02-16, Jonas Fonseca [off-list ref] wrote:

On Mon, Feb 16, 2009 at 02:33, Sitaram Chamarty [off-list ref] wrote:

quoted

On 2009-02-15, Jonas Fonseca [off-list ref] wrote:

quoted

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.

2009/2/16 Sitaram Chamarty [off-list ref]:

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

On Mon, Feb 16, 2009 at 16:25, Thomas Adam [off-list ref] wrote:

2009/2/16 Sitaram Chamarty [off-list ref]:

quoted

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

On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca  
[off-list ref] wrote:

On Fri, Feb 13, 2009 at 00:14, Tilo Schwarz [off-list ref] wrote:

quoted

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

On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca  
[off-list ref] 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

On Mon, Feb 16, 2009 at 20:52, Jonas Fonseca [off-list ref] 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

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 [off-list ref]

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

On Fri, Feb 20, 2009 at 18:24, Ted Pavlic [off-list ref] wrote:

quoted

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

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[off-list ref]  wrote:

quoted

quoted

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 [off-list ref]

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

On Fri, Feb 20, 2009 at 21:36, Ted Pavlic [off-list ref] 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

On Mon, Feb 16, 2009 at 22:12, Tilo Schwarz [off-list ref] wrote:

On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca [off-list ref]
wrote:

quoted

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.

quoted

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

On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca  
[off-list ref] 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!

quoted

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

On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz [off-list ref] wrote:

On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca [off-list ref]
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

On Sat, 21 Feb 2009 18:41:51 +0100, Jonas Fonseca  
[off-list ref] wrote:

On Sat, Feb 21, 2009 at 18:35, Tilo Schwarz [off-list ref] wrote:

quoted

On Sat, 21 Feb 2009 00:35:59 +0100, Jonas Fonseca  
[off-list ref]
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

On Fri, Feb 20, 2009 at 21:36, Ted Pavlic [off-list ref] 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