On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote: > I suspect we should make the thing a config option, and default it to > "on". Agreed. That would be fabulous! > That's really the reason why git defaults to not showing the root diff at > all: exactly because for the kernel, the initial commit was state that > "just came to be", and I found it both illogical and annoying to see it as > a diff, since that commit really was a "black hole" where previous history > just disappeared. Ah, that's a rationale I wouldn't have guessed. > There's also another reason for the root being special, which is purely > git-internal: the root really has no parents at all, and the normal "git > diff" is "diff against parents". This is the rationale I was guessing was the cause. It clearly takes a special case in the code to show the root diff, and --root seemed like that special-case implementation leaking into the interface, (where, usually, the user wouldn't expect the first commit to be any different than any other). This looks like yet another case where a feature was added, and a new command-line option with it, when what was really wanted was a new default. > git didn't end up doing that (and I'm personally pretty happy about it), It seems a reasonable enough decision, but it does have some impacts. Several of the tools don't work in the strange state between git-init and the first git-commit. Some of these are getting worked out now, (such as pull), but Junio was still objecting to fixing diff to work. There's a decision to have git's internals support this intermediate state, but all the tools should be made completely functional. This is an important things to get right, since this is the first state in which a new user will have her repository, (right after doing git-init-db as the first step in the tutorial). So it's important to make this state functional and not have to explain the "strange" implementation details "Normally, you would have a branch HEAD at this point, so these commands would usually work even though they don't yet, etc. etc." > So having a config option would solve the problem, If the default is fixed, yes. > but what annoys me > right now about the config options is that we really should have a > graphical front-end to setting those things or something, because while > _I_ don't have any issues with editing a ".git/config" file, I think we're > getting to the point where a lot of our problems are really about "you can > do it, but you have to know a lot about git to even know you can do it". I agree with that statement. But I also think that for the "new user problems" a new graphical tool for twiddling git options wouldn't make the system any less imposing. On the other hand, getting the defaults to be less surprising would definitely help, (and configuration options can be used to good effect to allow "old-timers" to maintain the behavior they're used to as defaults change). -Carl
Attachment:
pgp1hX2PcyvjD.pgp
Description: PGP signature