On Nov 7, 2007, at 6:03 PM, Jon Smirl wrote:
On 11/7/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
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
-
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
