gitk from subdirectory

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(-)

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

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/$/)/'

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

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

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

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'

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

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

"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(-)

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

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

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

Looks obviously correct.

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

		Linus

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

Thanks.