> You can use extended sha1 syntax, described in git-rev-parse(1) (although > it would be nice to have relevant parts of documentation repeated in > git-cat-file(1)), namely > git cat-file -p REV:file > (and you can use "git cat-file -p ::file" to get index/staging area > version) Yes; I didn't remember that one. However, it's still not friendly. > git-fsck-objects is needed only if something doesn't work when > it should. "git repack" is safe, "git repack -a -d" is almost safe, > while "git prune" is not. Yes - /I/ know that; bear in mind though that this is intended as a comparison against subversion for a user who doesn't want to know how it works. How is that sort of user meant to know when they should run each of these commands? Git doesn't tell them, it doesn't even give hints. As you say, "git-prune" is not necessarilly safe - how does a new user know that? It's in the output of "git". > Perhaps git-archive should support "tree" format, i.e. writing > unversioned copy of a tree to filesystem. I think git is pretty good in the archive department. git-archive does exactly what it says on the tin, which is exactly what you would want. > There was discussion about adding thin wrapper around git-update-index > to specifically mark resolved merge conflicts. The option to pick up > ours, theirs, ancestor version is another argument for having such command. I think it's definitely a good idea. If you introduce git-update-index as a command a normal user will type, you've got a lot of explaining to do as to what else it does and why it does it. > It can be done without pipes: "git cat-file -p REV:file". > You can use aliases to have shorter name for that. This is the problem though. I realise that git can technically do an awful lot of these things, how many new users are going to stick around when you tell them that they have to learn about the config file and aliases before they can use the command they want? > Hmmm... I thought that some progress indicator of download/upload was > added... guess I was wrong. You're not wrong, there is a progress indicator, but it's measured in "objects" not megabytes. It's got a percentage as well. Neither of these things is a whole lot of use if I want to know how much data (in megabytes) has been transferred, how much is there left to go and how long is it going to take. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@xxxxxxxxx - 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