login
Search
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 ...
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 杜甫 天末懷李白
涼風起天末 君子意如何 鴻雁幾時到 江湖秋水多
文章憎命達 魑魅喜人過 應共冤魂語 投詩贈汨羅
--
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 --
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 --
Good to hear. I remember you posted a patch for this after 0.11 was 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 --
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 --
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 --
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
--
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 --
So it ist somewhat safe to assume that the line didn't originate from 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 --
Hmm, this is trivially fixed by passing -M to git blame so maybe that should just be the default for tig. -- Jonas Fonseca --
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 --
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 --
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 ...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 --
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 ...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 --
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
--
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 --
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 --
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 --
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 --
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.
--
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 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 --
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 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 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 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
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 --
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. --
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.
--
The basic idea of the "cursor line" is that the whole line including 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 --
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.
--
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.
--
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
--
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.
--
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
OS X 10.4.11
iTerm 0.9.6.1201
TERM=xterm-color
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.
--
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.
--
> 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.
--
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 Yes, good idea. The blame and main view currently does this too. Will 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 It will probably take a some time to get there, but I am open to moving in this direction. -- Jonas Fonseca --
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
--
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
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
--
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 Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca 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 Ahh, ok, so tig would issue a prompt and ask me for the ...
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 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 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 Yes please. -- Jonas Fonseca --
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:
- 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
--
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
That was quick! I can't trigger the SIGSEGV anymore.
Regards,
Tilo
--
On Mon, 16 Feb 2009 00:47:05 +0100, Jonas Fonseca
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
--
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 李益 江南曲
嫁得瞿塘賈 朝朝誤妾期 早知潮有信 嫁與弄潮兒
--
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 --
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 李商隱 錦瑟
錦瑟無端五十絃 一絃一柱思華年 莊生曉夢迷蝴蝶 望帝春心託杜鵑
滄海月明珠有淚 藍田日暖玉生煙 此情可待成追憶 只是當時已惘然
--
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 --