gitk from subdirectory

gitk from subdirectory

[Junio C Hamano]

Since commit cdaee5db165ba8bae8d3b524950e61666fc36a84 (gitk:
Improve handling of -- and ambiguous arguments), running gitk
from a subdirectory limits the displayed history with the
current directory as the path limiter, because it always passes
the "--" to the underlying git-rev-list.

One obvious side effect of this is if you create a new directory
and cd to it, gitk will not show anything because no commit in
the history has touched the path you are currently in.

I am wondering if this was intended behaviour change.  I think
it makes sense to want an easy way to say "what changed stuff in
the directory I am in?" because presumably you are there because
you are interested in stuff in there.  But if you hard code "--"
it is not easy to disable that and get the global log.

You always can say "gitk -- ." to limit commits to the current
directory, so it might have been just an oversight.  In which
case, the attached patch may be needed to restore the old
behaviour.

Signed-off-by: Junio C Hamano <junkio@pobox.com>
---
 gitk |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/gitk b/gitk
index 300fdce..b95b313 100755
--- a/gitk
+++ b/gitk
@@ -92,8 +92,13 @@ proc start_rev_list {view} {
 	set order "--date-order"
     }
     if {[catch {
+	if {[llength $viewfiles($view)] == 0} {
+	    set rlpaths {}
+	} else {
+	    set rlpaths [list "--" $viewfiles($view)]
+	}
 	set fd [open [concat | git log -z --pretty=raw $order --parents \
-			 --boundary $viewargs($view) "--" $viewfiles($view)] r]
+			 --boundary $viewargs($view) $rlpaths] r]
     } err]} {
 	error_popup "Error executing git rev-list: $err"
 	exit 1

Re: gitk from subdirectory

[Junio C Hamano]

Junio C Hamano <junkio@pobox.com> writes:

> Since commit cdaee5db165ba8bae8d3b524950e61666fc36a84 (gitk:
> Improve handling of -- and ambiguous arguments), running gitk
> from a subdirectory limits the displayed history with the ...

FYI, I picked up your wish in the kernel list and have been
experimenting with this 5-liner whenever I refer to a commit in
the past:

        #!/bin/sh
        for commit
        do
                git show -s --pretty=oneline "$commit"
        done |
        sed -e 's/^[^ ]* /&(/' -e 's/$/)/'

Re: gitk from subdirectory

[Linus Torvalds]

On Thu, 30 Aug 2007, Junio C Hamano wrote:
> 
> I am wondering if this was intended behaviour change.  I think
> it makes sense to want an easy way to say "what changed stuff in
> the directory I am in?" because presumably you are there because
> you are interested in stuff in there.  But if you hard code "--"
> it is not easy to disable that and get the global log.

Hmm. My reaction to this would be that it was a mistake to have a 
difference between 

	git log --

and

	git log

and that we should instead fix this at the argument parsing level. 

And then anybody who depended on the old "--" behaviour can just add a "." 
at the end.

That way there are no special cases.

I realize that the "--" behaviour of git log was intentional, but seeing 
what it results in I think the intention was good, but stupid.

		Linus

Re: gitk from subdirectory

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 30 Aug 2007, Junio C Hamano wrote:
>> 
>> I am wondering if this was intended behaviour change.  I think
>> it makes sense to want an easy way to say "what changed stuff in
>> the directory I am in?" because presumably you are there because
>> you are interested in stuff in there.  But if you hard code "--"
>> it is not easy to disable that and get the global log.
>
> Hmm. My reaction to this would be that it was a mistake to have a 
> difference between 
>
> 	git log --
>
> and
>
> 	git log
>
> and that we should instead fix this at the argument parsing level. 
>
> And then anybody who depended on the old "--" behaviour can just add a "." 
> at the end.
>
> That way there are no special cases.
>
> I realize that the "--" behaviour of git log was intentional, but seeing 
> what it results in I think the intention was good, but stupid.

I haven't finished analysis yet, but I was reaching the same
conclusion.

v1.2.0 used to limit "git rev-list" to the current working
directory, v1.3.0 and newer does not.  But they do when "--" is
given.  This makes it impossible to do:

	cd Documentation
	echo >master
	git rev-list master
        ... get "ambiguous -- which do you mean?  rev, or
	... limited to path?" error message
        git rev-list master --
        ... I do mean unlimited and dig from 'master'

Re: gitk from subdirectory

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> I realize that the "--" behaviour of git log was intentional, but seeing 
>> what it results in I think the intention was good, but stupid.
>
> I haven't finished analysis yet, but I was reaching the same
> conclusion.
>
> v1.2.0 used to limit "git rev-list" to the current working
> directory, v1.3.0 and newer does not.  But they do when "--" is
> given.  This makes it impossible to do:
>
> 	cd Documentation
> 	echo >master
> 	git rev-list master
>         ... get "ambiguous -- which do you mean?  rev, or
> 	... limited to path?" error message
>         git rev-list master --
>         ... I do mean unlimited and dig from 'master'

FWIW bisect points at your commit ae563542bf10fa8c33abd2a354e4b28aca4264d7
(First cut at libifying revlist generation) ;-).

Re: gitk from subdirectory

[Junio C Hamano]

"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so.  It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
libifying revlist generation).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 revision.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/revision.c b/revision.c
index 51fff0e..c193c3e 100644
--- a/revision.c
+++ b/revision.c
@@ -896,7 +896,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 			continue;
 		argv[i] = NULL;
 		argc = i;
-		revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
+		if (argv[i + 1])
+			revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
 		seen_dashdash = 1;
 		break;
 	}

Re: gitk from subdirectory

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> "git log" family of commands, even when run from a subdirectory,
> do not limit the revision range with the current directory as
> the path limiter, but with double-dash without any paths after
> it, i.e. "git log --" do so.  It was a mistake to have a
> difference between "git log --" and "git log" introduced in
> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
> libifying revlist generation).
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

In case it was not obvious, this patch is meant to make the
previous patch from me to change gitk unneeded.

Re: gitk from subdirectory

[Linus Torvalds]

On Thu, 30 Aug 2007, Junio C Hamano wrote:

> "git log" family of commands, even when run from a subdirectory,
> do not limit the revision range with the current directory as
> the path limiter, but with double-dash without any paths after
> it, i.e. "git log --" do so.  It was a mistake to have a
> difference between "git log --" and "git log" introduced in
> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
> libifying revlist generation).
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Looks obviously correct.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>

		Linus

Re: gitk from subdirectory

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 30 Aug 2007, Junio C Hamano wrote:
>
>> "git log" family of commands, even when run from a subdirectory,
>> do not limit the revision range with the current directory as
>> the path limiter, but with double-dash without any paths after
>> it, i.e. "git log --" do so.  It was a mistake to have a
>> difference between "git log --" and "git log" introduced in
>> commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
>> libifying revlist generation).
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Looks obviously correct.
>
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>

Thanks.