Re: [tig] Feeding specific revisions to tig

["Jonas Fonseca" <jonas.fonseca@gmail.com>]

Sorry for restarting this old thread ...

On Thu, Jun 5, 2008 at 01:08, Jeff King <peff@peff.net> wrote:
> On Wed, Jun 04, 2008 at 10:04:45PM +0200, Jean-Baptiste Quenot wrote:
>
>> Thanks for the suggestion.  However, my list of commits is too long,
>> the shell errors out with "tig: command too long".  I'd like to feed
>> tig with a list of commits from stdin, or from a file.
>>
>> Something like: ... | tig --no-walk -F -
>>
>> Which means: take the list of revisions from specified file, or here -
>> for stdin, a la grep.
>
> Ah. Adding "-F" probably wouldn't be that much work, but tig spawns "git
> log" internally, so you would probably end up with the same problem
> there. Converting tig to use "git rev-list --stdin" would fix that, but
> is probably a bit of major surgery.

git-rev-list expects a commit as an argument while git-log does not. I
have been gradually changing the option parsing code to move towards
using git-rev-parse for splitting up arguments so it will be possible
to support refreshing better and pass user arguments to the diff
engine etc. When the code will get there it probably won't be that
hard to switch to use git-rev-list.

I actually added something that let's you alter the command executed
for each view. So here is another possibility that can be used:

function tignowalk ()
{
   tmp=$(mktemp) # or .git/tigfiles or similar
   # Safe stuff from "stdin" and run tig with custom rev-list command
   cat > "$tmp
   TIG_MAIN_CMD="git rev-list --pretty=raw --no-walk --stdin < $tmp"
tig < /dev/tty
   rm "$tmp"
}

And then:

   printf "tig-0.2\ntig-0.1" | tignowalk

On Wed, Jun 4, 2008 at 22:04, Jean-Baptiste Quenot <jbq@caraldi.com> wrote:
> 2008/6/4 Jeff King <peff@peff.net>:
>>     Though it seems there are a few display artifacts. If I do
>>
>>       tig --no-walk tig-0.1 tig-0.2
>>
>>     I get the 2 commits I expect, but also two "extra" blank
>>     commits at the bottom.
>
> I confirm there are extra blank lines at the bottom.  As many as real
> commit lines.

The problem is that --no-walk doesn't seem to play nice with the
--boundary flag that tig add by default. When the user requests
--no-walk boundary commits are probably not interesting. My fix below
has more information. I don't know if having only the "commit" line
show up is a bug in git. At least there are no tests to confirm this
or not.

commit ad9f9954419b5d3f595580d5184db59a00711f92
Author: Jonas Fonseca <fonseca@diku.dk>
Date:   Tue Aug 5 23:40:21 2008 +0200

    Clean up incomplete commits from main view listed for --no-walk

    When --no-walk is given on the command line by the user it causes
    boundary commits to be output with just the commit line, i.e:

      > git rev-list --pretty=raw --boundary --no-walk HEAD
      commit 60e8ea56880fc2e42008075d516c356ef605bc60
      tree 5b76086e4deaf62d3f7baffc6f49840f61d4e79c
      parent 145194bdfc8bf0b58185bbe28bc0097ce429de4d
      author Jonas Fonseca <fonseca@diku.dk> 1217797175 +0200
      committer Jonas Fonseca <fonseca@diku.dk> 1217797402 +0200

          Remove the global opt_request variable

      commit -145194bdfc8bf0b58185bbe28bc0097ce429de4d

diff --git a/NEWS b/NEWS
index b7a8df1..d93fb04 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,7 @@ Bug fixes:
    keybinding to launch the merge tool in the status view.
  - Fix problem with $(cmd) usage in shell code. Some shells (jsh)
    installed as /bin/sh does not support it.
+ - Do not show incomplete boundary commits when --no-walk is used.
  - Documentation: Rename gitlink macro to support AsciiDoc 8.2.3.

 tig-0.11
diff --git a/tig.c b/tig.c
index 6846519..6b111e4 100644
--- a/tig.c
+++ b/tig.c
@@ -4983,6 +4983,14 @@ main_read(struct view *view, char *line)
 	if (!line) {
 		if (!view->lines && !view->parent)
 			die("No revisions match the given arguments.");
+		if (view->lines > 0) {
+			commit = view->line[view->lines - 1].data;
+			if (!*commit->author) {
+				view->lines--;
+				free(commit);
+				graph->commit = NULL;
+			}
+		}
 		update_rev_graph(graph);
 		return TRUE;
 	}

-- 
Jonas Fonseca