Sorry for restarting this old thread ...
On Thu, Jun 5, 2008 at 01:08, Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxx> wrote:
> 2008/6/4 Jeff King <peff@xxxxxxxx>:
>> 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@xxxxxxx>
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@xxxxxxx> 1217797175 +0200
committer Jonas Fonseca <fonseca@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
