On Wed, 20 Dec 2006 15:36:51 -0800, Junio C Hamano wrote: > Do you have comments on recent changes (both on 'master' and > some parts of 'next') from teachability point of view? I think > you are "the guilty guy" who defined the theme for v1.5.0 to be > "usability and teachability" ;-). I'm flattered to be blamed for what I consider a very good theme for the release. I don't have a lot of detailed comments right now other than to repeat a "good job!" to everyone who has done a lot to improve things lately, (coming up with more use-oriented documentation, adding a reasonable shorthand "add"[*] for update-index, cleaning up a lot of bad error message and needless spew, making much more reasonable default clone behavior, etc. etc.). I think git's really come a long ways as far as usability and teachability, (while nothing fundamental has really changed and old-time users should hardly notice anything different). I think I'll have a few minor tweaks to suggest to the documentation if I get a chance to take a detailed pass over it, (which I hope to do before the new year). And I'd definitely like to enable "git checkout <revision>" with a new complaint on git-commit before the 1.5 release. I'll see if I can't find time to work on implementing that. -Carl [*] I'm still somewhat unsettled that the "new" add command conflates the notions of adding content into the index for paths that previously didn't exist in the index with the notion of updating the content in the index for paths that did exist already. I think those notions are generally distinct from the users point of view---the first changes a file's state in a fundamental way, (from "untracked" to "tracked"), while the second merely updates its content with no change to its state. One way to see the distinction is to imagine two different useful operations "add all untracked file paths to the index" and "update content for all tracked paths". If we had separate commands for 'add' and 'update' then it would be natural to express these two variants with "git add --all" and "git update --all". As things stand now, the first operation is available already with "git add .", (and oddly, with "git add", and I agree that should be removed). Meanwhile the second operation is not currently available in git, (but I recently proposed it as "git add -a|--all" in response to a request). As pointed out in that thread, there's a bit of a problem in that "git add --all" is really easy to mistake for a command that would add all untracked files to the index, (since it's when adding new paths that people will most often use "git add" so it will naturally be associated with adding new paths). It's less likely for users to establish the "update content" notion of "git add" since it often won't be needed at all, (tutorials and the git-commit documentation recommend "commit -a" to avoid the need to use "git add" in its updating sense). So, to summarize, I think it's good to have a much shorter command to type than "update-index" for the update-content-of-path-in-index operation. So using "add" for this is better than "update-index" already. And if that's how it stays, I can certainly live with it. But I think it might be even better if the updating notion were on a separate command name (update ? stage ?), and this in spite of the fact that fewer commands is generally better for learnability. It's not a major issue---and it's nothing that I would make a big fuss over, so feel free to ignore it if it appears a non-issue to you.
Attachment:
pgprM85YaToa6.pgp
Description: PGP signature