From: Brian Gernhardt Date: Wed, 07 Nov 2007 23:19:24 GMT Subject: Re: Inconsistencies with git log Message-ID: <243E1E6E-4723-42D3-933C-D2A0D1ACE287@silverinsanity.com> In-Reply-To: <9e4733910711071503va92a653s25fd978989d5917d@mail.gmail.com> On Nov 7, 2007, at 6:03 PM, Jon Smirl wrote: > On 11/7/07, Johannes Schindelin 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