Re: svn versus git

[Andy Parkins <andyparkins@gmail.com>]

> 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