Re: Inconsistencies with git log
- From
Brian Gernhardt <benji@silverinsanity.com>
- Date
- Nov 7, 2007, 23:19 UTC
- 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:
Show 8 quoted lines
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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