Inconsistencies with git log

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

still in arch/powerpc/platforms/52xx
git log
get log for the whole project

Shouldn't git log give the the log for the tree under the current directory?

jonsmirl@terra:~/mpc5200b/arch/powerpc/platforms/52xx$ git --version
git version 1.5.3.4.1458.g3e72e

-- 
Jon Smirl
jonsmirl@gmail.com

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

Try "git log ."

Hth,
Dscho

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

Try "git log ."

Shouldn't git log default to "git log ."?

-- 
Jon Smirl
jonsmirl@gmail.com

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

Try "git log ."

Shouldn't git log default to "git log ."?

Well, it is in line with the other commands being able to work on 
subdirectories, but doing the whole repository operation by default.

We also tend to take the approach of viewing the history as that of 
the whole project.

This approach also means that it is a much more expensive operation to log 
the history as seen by a subdirectory, which is another reason why it is 
not the default.

Hth,
Dscho

On Nov 8, 2007 9:45 AM, Jon Smirl [off-list ref] wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

Try "git log ."

Shouldn't git log default to "git log ."?

It might be nice if it did, but since Git tracks whole *trees* (not
files) then it makes more sense to show the log of the repository in
its default mode.

On the other hand, it'd sure be nice if git-status would show relative
paths when you're in subdirectories, especially when you're in a
deeply nested directory hierarchy. It's a lot easier to see that
"foo.txt" and "../bar.txt" have modifications. Furthermore, it is the
relative path that you have to pass to git-add anyway, so quick
copy-n-pasting from git-status output often doesn't work.


Dave.

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

Shouldn't git log default to "git log ."?

Well, it is in line with the other commands being able to work on
subdirectories, but doing the whole repository operation by default.

I agree with this and see how it got this way.

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

This approach also means that it is a much more expensive operation to log
the history as seen by a subdirectory, which is another reason why it is
not the default.

Hth,
Dscho

-- 
Jon Smirl
jonsmirl@gmail.com

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of 
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log 
is almost never what you want. It's this kind of thing that makes git 
harder to use.

When I am working in a subdirectory, I often want the whole history.  For 
example, when I am working on the documentation, sometimes I need to look 
up a commit real quick, that touched other parts.

Besides, adding a space and a dot is not what qualifies for "harder to 
use" with this developer.

Ciao,
Dscho

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

Besides, adding a space and a dot is not what qualifies for "harder to
use" with this developer.

It requires teaching people new to git to add the space dot.

-- 
Jon Smirl
jonsmirl@gmail.com

On Nov 7, 2007, at 6:03 PM, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

Here's where I'd have to disagree with you.  If I'm in git.git/ 
Documentation and am trying to remember which commit I'm trying to  
document, suddenly having 90+% of the history vanish would make git  
harder to use.  Same with my rails projects, my mudlib, etc.  Hiding  
history is a bad default.

I think the problem is that you're still thinking in the CVS-style per- 
file history.  "git log" works on the history not the files, so the  
automatic filtering simply doesn't make sense.  Git's whole-tree  
approach makes it much easier to find when Makefile or API changes  
have broken your code.  But if you know that the error is in a  
specific place, then using "." lets you get at it.

However, Dave's suggestion of altering git-status output to be  
relative to (but not limited by) CWD has merit.  Too bad I don't have  
time to work on it right now.

~~ Brian Gernhardt

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

When I am working in a subdirectory, I often want the whole history.  For
example, when I am working on the documentation, sometimes I need to look
up a commit real quick, that touched other parts.

Besides, adding a space and a dot is not what qualifies for "harder to
use" with this developer.

So if git log is always whole tree, why doesn't this work?

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.

-- 
Jon Smirl
jonsmirl@gmail.com

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.


Dave.

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

So if git log is always whole tree, why doesn't this work?

git log is not always the whole tree.  git log without arguments is.

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

It's not consistent. git log with no parameters is relative to the 
project root, git log with a parameter is relative to the current 
directory.

It is consistent, when you realise that the path arguments are interpreted 
relative to the project root.

Hth,
Dscho

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

It is consistent, when you realise that the path arguments are interpreted
relative to the project root.

Then why doesn't this work?

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
fatal: ambiguous argument 'Documentation': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
jonsmirl@terra:~/mpc5200b/Documentation$

Hth,
Dscho

-- 
Jon Smirl
jonsmirl@gmail.com

Hi,

On Thu, 8 Nov 2007, David Symonds wrote:

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be 
relative to (but not limited by) CWD has merit.  Too bad I don't have 
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the 
concept.

Too late ;-)

Ciao,
Dscho

When a struct in wt-status.h changes, many files need to be rebuilt.

Signed-off-by: Johannes Schindelin <redacted>
---
 Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index e5dc63b..dad9c5a 100644
--- a/Makefile
+++ b/Makefile

@@ -288,7 +288,8 @@ LIB_H = \
 	run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
 	tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
 	utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
-	mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h
+	mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h \
+	wt-status.h
 
 DIFF_OBJS = \
 	diff.o diff-lib.o diffcore-break.o diffcore-order.o \

-- 
1.5.3.5.1597.g7191

Signed-off-by: Johannes Schindelin <redacted>
---

	This looks a bit ugly because quote_crlf() is now also called
	on the untracked files, which are not NUL terminated.

	Maybe someone has an idea how to do this more elegantly.

 builtin-runstatus.c |    1 +
 wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
 wt-status.h         |    1 +
 3 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c

@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
 
 	git_config(git_status_config);
 	wt_status_prepare(&s);
+	s.prefix = prefix;
 
 	for (i = 1; i < argc; i++) {
 		if (!strcmp(argv[i], "--color"))

diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..7386d41 100644
--- a/wt-status.c
+++ b/wt-status.c

@@ -82,16 +82,48 @@ static void wt_status_print_trailer(struct wt_status *s)
 	color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
 }
 
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
+	const char *prefix)
 {
 	const char *scan;
 	char *out;
 	const char *ret = in;
+	int off = 0;
+
+	if (len < 0)
+		len = strlen(in);
+
+	if (prefix) {
+		while (prefix[off] && off < len && prefix[off] == in[off])
+			if (prefix[off] == '/') {
+				prefix += off + 1;
+				in += off + 1;
+				len -= off + 1;
+				off = 0;
+			} else
+				off++;
+		for (off = 0; *prefix; prefix++)
+			if (*prefix == '/') {
+				if (off + 4 >= sz) {
+					warning ("Could not prefix path: %s",
+						in);
+					return in;
+				}
+				strcpy(buf + off, "../");
+				off += 3;
+			}
+		ret = buf;
+	}
 
-	for (scan = in, out = buf; *scan; scan++) {
+	for (scan = in, out = buf + off; len; scan++, len--) {
 		int ch = *scan;
 		int quoted;
 
+		if (out - buf + 3 >= sz) {
+			warning ("Could not quote path: %s", in);
+			break;
+		}
+
 		switch (ch) {
 		case '\n':
 			quoted = 'n';

@@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
 	const char *one, *two;
 	char onebuf[PATH_MAX], twobuf[PATH_MAX];
 
-	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
-	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+	one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
+	two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
 
 	color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 	switch (p->status) {

@@ -215,8 +247,8 @@ static void wt_status_print_initial(struct wt_status *s)
 	for (i = 0; i < active_nr; i++) {
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 		color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
-				quote_crlf(active_cache[i]->name,
-					   buf, sizeof(buf)));
+				quote_crlf(active_cache[i]->name, -1,
+					   buf, sizeof(buf), s->prefix));
 	}
 	if (active_nr)
 		wt_status_print_trailer(s);

@@ -254,6 +286,7 @@ static void wt_status_print_untracked(struct wt_status *s)
 	const char *x;
 	int i;
 	int shown_header = 0;
+	char buf[PATH_MAX];
 
 	memset(&dir, 0, sizeof(dir));
 

@@ -291,8 +324,9 @@ static void wt_status_print_untracked(struct wt_status *s)
 			shown_header = 1;
 		}
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
-		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
-				ent->len, ent->name);
+		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+				quote_crlf(ent->name, ent->len,
+					buf, sizeof(buf), s->prefix));
 	}
 }
 

diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h

@@ -23,6 +23,7 @@ struct wt_status {
 	int workdir_untracked;
 	const char *index_file;
 	FILE *fp;
+	const char *prefix;
 };
 
 int git_status_config(const char *var, const char *value);

-- 
1.5.3.5.1597.g7191

On Nov 8, 2007 11:09 AM, Johannes Schindelin [off-list ref] wrote:

Hi,


On Thu, 8 Nov 2007, David Symonds wrote:

quoted

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the
concept.

Too late ;-)

I see that you're revolting against relative paths in git-log; I agree
with you on that. I'm proposing changing the output to git-status so
that it produces relative paths, which are suitable for
git-add/git-rm/git-diff/...


Dave.

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

It is consistent, when you realise that the path arguments are interpreted
relative to the project root.

Then why doesn't this work?

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
fatal: ambiguous argument 'Documentation': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions

Because you are in the subdirectory Documentation/, relative to the 
project root.  So when you say "Documentation", it tries to find the 
file/directory Documentation/Documentation.

Therefore, just say "git log ." and you will get what you want.

Ciao,
Dscho

On Nov 7, 2007, at 7:14 PM, David Symonds wrote:

On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de 

quoted

wrote:
Too late ;-)

I see that you're revolting against relative paths in git-log; I agree
with you on that. I'm proposing changing the output to git-status so
that it produces relative paths

Johannes was referring to the fact that he already produced that  
patches for it.  :-)

~~ Brian

On Nov 8, 2007 11:12 AM, Johannes Schindelin [off-list ref] wrote:

Signed-off-by: Johannes Schindelin <redacted>
---

        This looks a bit ugly because quote_crlf() is now also called
        on the untracked files, which are not NUL terminated.

        Maybe someone has an idea how to do this more elegantly.

 builtin-runstatus.c |    1 +
 wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
 wt-status.h         |    1 +
 3 files changed, 44 insertions(+), 8 deletions(-)

Tested, and looks good.

Now that I play with it, though, it seems that a few other bits of git
need updating to handle relative paths okay:

$ cd gitweb/test
$ rm ../../wt-status.h
    [oops, what a silly thing to do -- better checkout the latest
revision of it]
$ git status
# On branch next
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#       deleted:    ../../wt-status.h
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout HEAD ../../wt-status.h
fatal: git-ls-files: cannot generate relative filenames containing '..'
    [grr....]
$ cd ../..
$ git checkout HEAD .
    [that works]



Dave.

Hi,

On Thu, 8 Nov 2007, David Symonds wrote:

On Nov 8, 2007 11:12 AM, Johannes Schindelin [off-list ref] wrote:

quoted

Signed-off-by: Johannes Schindelin <redacted>
---

        This looks a bit ugly because quote_crlf() is now also called
        on the untracked files, which are not NUL terminated.

        Maybe someone has an idea how to do this more elegantly.

 builtin-runstatus.c |    1 +
 wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
 wt-status.h         |    1 +
 3 files changed, 44 insertions(+), 8 deletions(-)

Tested, and looks good.

Now that I play with it, though, it seems that a few other bits of git
need updating to handle relative paths okay:

$ cd gitweb/test
$ rm ../../wt-status.h
    [oops, what a silly thing to do -- better checkout the latest
revision of it]
$ git status
# On branch next
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#       deleted:    ../../wt-status.h
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout HEAD ../../wt-status.h
fatal: git-ls-files: cannot generate relative filenames containing '..'
    [grr....]
$ cd ../..
$ git checkout HEAD .
    [that works]

Well, now that I did all the hard work with git-status, I leave this easy 
exercise for you ;-)

Ciao,
Dscho

David Symonds wrote:

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

So perhaps git-commit -a should also be path-delimited, but where would we
end up then? It might be better to just let git-status accept a path
delimiter and let the path delimiter default to current work-dir.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

It is consistent, when you realise that the path arguments are interpreted
relative to the project root.

Then why doesn't this work?

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
fatal: ambiguous argument 'Documentation': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
jonsmirl@terra:~/mpc5200b/Documentation$

Because your current working directory, relative to the project root, is
prepended to the path you're in, so git sees "Documentation/Documentation".
I'm unsure why

	cd Documentation; git log -- /Documentation

doesn't do the trick though. I know that particular trick used to work for
some other command a while back anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

On Thu, Nov 08, 2007 at 01:11:01AM +0100, Andreas Ericsson wrote:

David Symonds wrote:

quoted

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

So perhaps git-commit -a should also be path-delimited, but where would we
end up then? It might be better to just let git-status accept a path
delimiter and let the path delimiter default to current work-dir.

I agree that 'git status' should show the *whole* tree and if it will work
in subdirectories with 'git status .' or 'git status Documentation', it
would be a nice UI improvement.

But please don't make it always show only the current subdir.

-Peter

El 8/11/2007, a las 0:03, Jon Smirl escribió:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

At least in my case, that's completely untrue. Whole-project history  
is basically *always* what I want even if I am cd'd into a  
subdirectory. If I wanted to path-limit the project history I'd do  
"git log ."

Cheers,
Wincent

El 8/11/2007, a las 0:29, Jon Smirl escribió:

It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.

A minor quibble: git log with no parameters isn't "relative" to  
anything. It shows the history of the entire project. There is no  
inconsistency.

Cheers,
Wincent

On Nov 8, 2007 11:11 AM, Andreas Ericsson [off-list ref] wrote:

David Symonds wrote:

quoted

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.


Dave.

David Symonds wrote:

On Nov 8, 2007 11:11 AM, Andreas Ericsson [off-list ref] wrote:

quoted

David Symonds wrote:

quoted

On Nov 8, 2007 10:19 AM, Brian Gernhardt [off-list ref] wrote:

quoted

However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit.  Too bad I don't have
time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.

Ah, that'd be a different matter entirely then. Thanks for clarifying. I
have no further objections then.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

On Wed, 7 Nov 2007, Jon Smirl wrote:

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

On 11/7/07, Johannes Schindelin [off-list ref] wrote:

quoted

We also tend to take the approach of viewing the history as that of
the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

When I am working in a subdirectory, I often want the whole history.  For
example, when I am working on the documentation, sometimes I need to look
up a commit real quick, that touched other parts.

Besides, adding a space and a dot is not what qualifies for "harder to
use" with this developer.

So if git log is always whole tree, why doesn't this work?

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.

git log with no parameters is still relative to the current directory. 
It's just not limited by paths at all, so what it's relative to doesn't 
matter.

Since it shows is commits that change any of the given paths, the 
perfectly consistant thing to do without any paths would be to show no 
commits. Of course, that's totally useless, so we default to making no 
limitation instead.

If there were any other options that took paths or filenames, they'd be 
relative to the subdirectory, regardless of whether there were any paths, 
and having no paths would still show history for the project without 
regard to whether commits touch paths.

	-Daniel
*This .sig left intentionally blank*

David Symonds, Thu, Nov 08, 2007 14:16:59 +0100:

I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.

Relative? Like this?

$ cd project/foo/bar
$ git status
...
    M file1.c
    M file2.c
    M ../baz/file3.c
    R ../bax/file4 => file4.c

Alex Riesen, Thu, Nov 08, 2007 22:21:23 +0100:

David Symonds, Thu, Nov 08, 2007 14:16:59 +0100:

quoted

I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.

Relative? Like this?

$ cd project/foo/bar
$ git status
...
    M file1.c
    M file2.c
    M ../baz/file3.c
    R ../bax/file4 => file4.c

Oh, I see. Yes. Cool.

On Wed, 7 Nov 2007, Jon Smirl wrote:

Then why doesn't this work?

Jon, lookie here:

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation

Instead of the above sequence, do:

	jonsmirl@terra:~/mpc5200b$ ls Documentation
	.. all the files in Documentation ..
	jonsmirl@terra:~/mpc5200b$ cd Documentation
	jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation

and now tell me, why doesn't that work? And can't you see how *stupid* 
your complaint is?

The rule is:
 - git log without arguments gives the whole, unabridged, and full 
   history.
 - git log with arguments gives the *simplified* history for those 
   arguments.

But the arguments - if they exist - are always relative. You want things 
like filename completion to work. Making the pathname arguments absolute 
would be horrible. Think about it: it's just much more logical to always 
be able to say "I want the log for file xyz", and you don't want that to 
be absolute, since you shouldn't care where in the tree you are.

And the fact that git log gives the whole history when you don't give any 
arguments at all IN NO WAY makes it any more sensible to give "absolute" 
pathnames. The history being "whole" has nothing to do with the pathnames 
being "absolute". The two are totally independent issues.

			Linus

On 11/9/07, Linus Torvalds [off-list ref] wrote:

On Wed, 7 Nov 2007, Jon Smirl wrote:

quoted

Then why doesn't this work?

Jon, lookie here:

quoted

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation

Instead of the above sequence, do:

        jonsmirl@terra:~/mpc5200b$ ls Documentation
        .. all the files in Documentation ..
        jonsmirl@terra:~/mpc5200b$ cd Documentation
        jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation

and now tell me, why doesn't that work? And can't you see how *stupid*
your complaint is?

I never expected that to work it was just a response to the earlier
misstatement that the paths were relative to the project root. It
demonstrated that they were not.

The summary of this is that new users do not expect "git log" to give
them the whole log when the command is executed in a subdirectory.
This causes a training burden because of the unexpected behavior. They
try 'git log' and then I have to tell them to use "git log ."

The rule is:
 - git log without arguments gives the whole, unabridged, and full
   history.
 - git log with arguments gives the *simplified* history for those
   arguments.

But the arguments - if they exist - are always relative. You want things
like filename completion to work. Making the pathname arguments absolute
would be horrible. Think about it: it's just much more logical to always
be able to say "I want the log for file xyz", and you don't want that to
be absolute, since you shouldn't care where in the tree you are.

And the fact that git log gives the whole history when you don't give any
arguments at all IN NO WAY makes it any more sensible to give "absolute"
pathnames. The history being "whole" has nothing to do with the pathnames
being "absolute". The two are totally independent issues.

                        Linus

-- 
Jon Smirl
jonsmirl@gmail.com

On Fri, 9 Nov 2007, Jon Smirl wrote:

The summary of this is that new users do not expect "git log" to give
them the whole log when the command is executed in a subdirectory.
This causes a training burden because of the unexpected behavior. They
try 'git log' and then I have to tell them to use "git log ."

No. The summary is that *you* are confused.

The fact is, "git log" always has given the whole log, and there is no 
confusion at all. The only people who may be confused are people who 
misread the documentation on purpose, or who came from some broken other 
SCM, and are confused just because of *that*.

Git makes it very clear indeed at all points that it tracks whole history. 
It's a big deal. We *make* a big deal about it, and "git log" follows that 
very consistently.

In fact, even at the top-of-tree, "git log" and "git log ." are two 
totally different things, even if in practice the differences are often 
hard to see. But one gives the "full history", and the other gives the 
"simplified history for the pathnames given", and the two are REALLY 
REALLY different.

Try it. Do

	git log origin/pu > full
	git log origin/pu . > limited

in the git tree, and look at the differences (it might be useful to use 
gitk instead, and look at where the differences start! That visual 
difference is going to give you a lot more of an "Ahaa!" moment when you 
understand it). When you can explain and understand those differences, 
then you *really* understand git (and quite frankly, it's actually rather 
simple, but you have to really *think* about what those things things 
are).

Now, for normal use you never need to really to care. Git does a lot of 
things, and some random user will seldom need the full power of git, nor 
do they need to really care about why "git log ." and "git log" are 
actually not the same thing at all, even at the top level.

But you're blaming git for your *own* confusion, which probably comes from 
crap systems that don't even know what "history" is because they can't 
really track it right anyway.

		Linus

Jon Smirl wrote:

The summary of this is that new users do not expect "git log" to give
them the whole log when the command is executed in a subdirectory.
This causes a training burden because of the unexpected behavior. They
try 'git log' and then I have to tell them to use "git log ."

That's too bad, that they have to unlearn bad expectations. Having
"git log" _always_ meaning whole history is very useful. You can always
do "git log ." (two characters more); how do you propose to request
full history from within subdirectory if by default "git log" output
would limit history to current directory only?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Fri, 9 Nov 2007, Linus Torvalds wrote:

In fact, even at the top-of-tree, "git log" and "git log ." are two 
totally different things [...]

Btw, the reason (and really the *only* reason) this is interesting at all 
is just to show that the notion of "full history" and "relative pathnames" 
really have nothing to do with each other. They really are in totally 
different and orthogonal dimensions.

"Full history" is something that exist *independently* of the pathnames. 

So the fact is, "git log" on its own is really about the *project*. It is 
totally pathname-independent, and I'd argue that many people are often 
just interested in the explanations (even though you obviously can also 
see the patches and the files changed too!) so I seriously doubt that this 
is just an implementation issue or my personal hang-up.

In other words "git log" simply is something *global*. It doesn't matter 
where in the tree you are, the end result is the same - it's about the 
project as a whole.

In contrast, "git log <filename>" is fundamentally different. Now you're 
explicitly stating that it's not something global any more, and that it's 
about the *files*. That's also why "git log" and "git log ." are acually 
different even at the top level.

Because when you're interested in the files, by implication you're not 
interested in commits that don't change the files - and there can be such 
commits even when you give the *total* file list.  

			Linus

On 11/9/07, Linus Torvalds [off-list ref] wrote:

On Fri, 9 Nov 2007, Linus Torvalds wrote:

quoted

In fact, even at the top-of-tree, "git log" and "git log ." are two
totally different things [...]

Btw, the reason (and really the *only* reason) this is interesting at all
is just to show that the notion of "full history" and "relative pathnames"
really have nothing to do with each other. They really are in totally
different and orthogonal dimensions.

Should "git log" and "git log path"  have two different command names?

"Full history" is something that exist *independently* of the pathnames.

So the fact is, "git log" on its own is really about the *project*. It is
totally pathname-independent, and I'd argue that many people are often
just interested in the explanations (even though you obviously can also
see the patches and the files changed too!) so I seriously doubt that this
is just an implementation issue or my personal hang-up.

In other words "git log" simply is something *global*. It doesn't matter
where in the tree you are, the end result is the same - it's about the
project as a whole.

In contrast, "git log <filename>" is fundamentally different. Now you're
explicitly stating that it's not something global any more, and that it's
about the *files*. That's also why "git log" and "git log ." are acually
different even at the top level.

Because when you're interested in the files, by implication you're not
interested in commits that don't change the files - and there can be such
commits even when you give the *total* file list.

                        Linus

-- 
Jon Smirl
jonsmirl@gmail.com

On Fri, 9 Nov 2007, Jon Smirl wrote:

Should "git log" and "git log path"  have two different command names?

Do you think that would really help?

We actually have people complaining about the numebr of git commands 
already. And the thing is, "git log" is actually what things like "gitk" 
use to visualize the history, and all *those* commands want the two 
different modes too! You want a "global history" view in gitk, but you 
also want a "file limited view". So having two different commands is 
actually what people absolutely DO NOT want.

On the same note: several git commands have totally different fundamental 
behaviour based on arguments - in ways even more different than "git log". 
At least "git log" always shows a log, the arguments just change what 
*part* of the log they show.

For example, think about "git checkout": you can use it to check out 
individual files and directories, but you can obviously use it to switch 
branches (and create them!) too.  That's actually a much bigger difference 
than the different modes of "git log", but considering how many people 
have complained about "many different commands", I think people seem to be 
happier with commands that do somewhat related things just depending on 
the kinds of arguments they get.

		Linus

On Fri, Nov 09, 2007 at 09:53:00AM -0800, Linus Torvalds wrote:

On Fri, 9 Nov 2007, Linus Torvalds wrote:

quoted

In fact, even at the top-of-tree, "git log" and "git log ." are two 
totally different things [...]

Btw, the reason (and really the *only* reason) this is interesting at all 
is just to show that the notion of "full history" and "relative pathnames" 
really have nothing to do with each other. They really are in totally 
different and orthogonal dimensions.

"Full history" is something that exist *independently* of the pathnames. 

So the fact is, "git log" on its own is really about the *project*. It is 
totally pathname-independent, and I'd argue that many people are often 
just interested in the explanations (even though you obviously can also 
see the patches and the files changed too!) so I seriously doubt that this 
is just an implementation issue or my personal hang-up.

In other words "git log" simply is something *global*. It doesn't matter 
where in the tree you are, the end result is the same - it's about the 
project as a whole.

In contrast, "git log <filename>" is fundamentally different. Now you're 
explicitly stating that it's not something global any more, and that it's 
about the *files*. That's also why "git log" and "git log ." are acually 
different even at the top level.

Because when you're interested in the files, by implication you're not 
interested in commits that don't change the files - and there can be such 
commits even when you give the *total* file list.  

Hm. I tried to run your 'git log' and 'git log .' example and a diff
revealed that the output of those two isn't the same, contrary to what I
thought.

In the 'git-log .' case, there should be done a history simplification,
but then only commits which don't change anything are pruned and AFAIR
'git commit' doesn't allow this. Using core git, one could create commits
with the same tree as their parent, but I don't think that all the commits
which get removed in the '.' case where produced that way. There has to be
another case I can't figure out.

A little confused,
Peter

On Fri, 9 Nov 2007, Peter Baumann wrote:

Hm. I tried to run your 'git log' and 'git log .' example and a diff
revealed that the output of those two isn't the same, contrary to what I
thought.

Btw, you can *make* them the same by using

	git log --full-history --sparse .

which basically tells git that you do not want any of the history 
simplification that git log does by default.

There's two different kinds of simplifications (which is why there are two 
kinds of switches above):

 - the "simplify merges to just the parent that is identical"

   This basically means that if a merge result comes 100% from one of the 
   parents, by default we will only look at that parent. Using 
   --full-history avoids this.

 - the "dense" history, which removes simple commits that don't make any 
   changes

   This is the "--sparse" thing: it says that we're interested even in 
   regular commits that simply don't make any changes.

In the 'git-log .' case, there should be done a history simplification,
but then only commits which don't change anything are pruned and AFAIR
'git commit' doesn't allow this.

Actually, git itself creates these commits under several circumstances:

 - you can *force* it. No, "git commit" on its own doesn't allow it, but 
   you can do it quite easily with "git commit-tree" and setting things 
   up by hand.

 - you can import history from other SCM's. I think all importers will 
   honor other SCM's, and if they allow empty commits then the end result 
   will have empty commits in it too!

 - merges. This is the common case. You have a "git merge --ours" or 
   similar, which basically merges just one side (or, even without 
   "--ours", this is really common for the non-"." case: a merge just 
   doesn't touch some files at all). Then, the merge simplifier will first 
   turn it into a "single parent", and then densification will remove that 
   (now uninteresting) empty merge.

Using core git, one could create commits with the same tree as their 
parent, but I don't think that all the commits which get removed in the 
'.' case where produced that way. There has to be another case I can't 
figure out.

See above. Three cases, in fact.

		Linus