Gitk and --no-walk don't play together

Gitk and --no-walk don't play together

[Jan Engelhardt]

Hi,


in an attempt to only show only the tags in the graph, gitk barfs:

$ gitk --no-walk v2.6.25 v2.6.26
[ Error reading commits: child killed: segmentation violation ]

Re: Gitk and --no-walk don't play together

[Santi Bejar]

On Mon, Sep 8, 2008 at 6:25 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> Hi,
>
>
> in an attempt to only show only the tags in the graph, gitk barfs:

Use the "List references" in the file menu.

>
> $ gitk --no-walk v2.6.25 v2.6.26
> [ Error reading commits: child killed: segmentation violation ]

At least, you should say the git version, the OS and platform.

It is the child process that segfaults, you could try "git rev-list
--no-walk v2.6.25 v2.6.26" directly and even try to debug it?

Santi


> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Gitk and --no-walk don't play together

[Jan Engelhardt]

On Monday 2008-09-08 12:34, Santi Bejar wrote:
>
>> in an attempt to only show only the tags in the graph, gitk barfs:
>
>Use the "List references" in the file menu.

Nope, the intention was to have gitk display something like

* Linux 2.6.26
|
* Linux 2.6.25

without any intermediate commits.

>> $ gitk --no-walk v2.6.25 v2.6.26
>> [ Error reading commits: child killed: segmentation violation ]
>
>At least, you should say the git version, the OS and platform.

Right you are. gitk 1.5.4.3 and Linux 2.6.24.7.

>It is the child process that segfaults, you could try "git rev-list
>--no-walk v2.6.25 v2.6.26" directly and even try to debug it?

rev-list completes without any problems. I straced gitk, and see:

	git log --no-color -z --pretty=raw --topo-order
	--parents --boundary --no-walk v2.6.25 v2.6.26

To reproduce:

	git log [with all that arguments] >/dev/null; echo $?
	Segmentation fault
	139

It is fixed in v1.6.0.1-267-gec3a4ba. Bisect identified that 
3131b71 fixed it:

    Add "--show-all" revision walker flag for debugging


So case closed and thank you ;-)
Jan

Re: Gitk and --no-walk don't play together

[Santi Bejar]

On Mon, Sep 8, 2008 at 7:25 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Monday 2008-09-08 12:34, Santi Bejar wrote:
>>
>>> in an attempt to only show only the tags in the graph, gitk barfs:
>>
>>Use the "List references" in the file menu.
>
> Nope, the intention was to have gitk display something like
>
> * Linux 2.6.26
> |
> * Linux 2.6.25
>
> without any intermediate commits.
>

I think the only option is to generate a graft file specifying 2.6.25
as parent  of 2.6.26.

I have an script that generates it. It gives an overview of the
branches/tags, where the parents of a branch/tag are the independent
branches/tags that are antecesors (search for git-overview in the
list). But currently it has a very bad performance, it could be added
to git itself like the other history simplifications, but I don´t
know.

Santi

Re: Gitk and --no-walk don't play together

[Dmitry Potapov]

On Mon, Sep 08, 2008 at 01:25:12PM -0400, Jan Engelhardt wrote:
> rev-list completes without any problems. I straced gitk, and see:
> 
> 	git log --no-color -z --pretty=raw --topo-order
> 	--parents --boundary --no-walk v2.6.25 v2.6.26

git log crashed when it tried to print the boundary commit.
It seems the bug exists in all 1.5.4.x and was fixed in 1.5.5.
The commit that fixed the bug is 3131b71 when --show-all was added
to revision log. The lines that fixed this bug are the following:

> diff --git a/log-tree.c b/log-tree.c
> index 1f3fcf1..e9ba6df 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -278,6 +282,9 @@ void show_log(struct rev_info *opt, const char *sep)
>  		}
>  	}
>  
> +	if (!commit->buffer)
> +		return;
> +
>  	/*
>  	 * And then the pretty-printed message itself
>  	 */

Dmitry

Re: Gitk and --no-walk don't play together

[Junio C Hamano]

Jan Engelhardt <jengelh@medozas.de> writes:

> On Monday 2008-09-08 12:34, Santi Bejar wrote:
>>
>>> in an attempt to only show only the tags in the graph, gitk barfs:
>>
>>Use the "List references" in the file menu.
>
> Nope, the intention was to have gitk display something like
>
> * Linux 2.6.26
> |
> * Linux 2.6.25
>
> without any intermediate commits.

Aren't you being unreasonable?  How would gitk know to draw the line
between .25 and .26 without walking the history?