Re: GIT vs Other: Need argument

[Andy Parkins <andyparkins@gmail.com>]

On Thursday 2007 April 19 12:59, Marcin Kasperski wrote:
> > but git is definitely no harder to learn
> > than anything else.  I browsed through the mecurial tutorial
> > yesterday - and as well as being significantly less powerful than git,
> > it's no easier.
>
> Mercurial is easier to learn, because it has better docs and slightly
> simpler command line (all those -a, -p, ... options which one always
> forgets to add). I tried it.
> In fact, I did the experiment about month ago. I wanted to give a try
> to distributed vc tool. I started from GIT, played a bit with it, and
> abandoned it because a) I did not know whether I am expected to use git,
> or cg, b) While reading docs many times I had the feeling that something
> strange and unclear is going behind the hood.

In terms of normal operation, there aren't many switches one actually needs to 
remember.  The only one I can think of is "-a" for commit - however, that's 
just to make it work like mercurial - a seasoned git user won't use many 
switches.  My daily grind consists of

 git add file.c
 git commit
 git add file.c
 git commit
 git add -i
 git commit

(Interactive mode for git-add is a joy to use - I don't know if Mercurial has 
anything similar).

Now, to your point.  I think you're right.  What I said was that git actually 
is easier; however if you looked at some of the documentation you would 
incorrectly assume that that was not the case.

> > (I can't believe this one - if you want to branch a mercurial repository
> > you have to have another complete checkout.  Erm... the checkout takes
> > up more space than the repository - why do I need another copy? Anyway,
> > git is no harder than Mercurial here)
>
> AFAIK you are wrong, they are able to link some files while cloning, so

Can't be.  I'm talking about the working directory not the repository - if the 
files are linked back to the originals, then it's not a separately editable 
set of files is it?

> you loose space only if you switch machine or filesystem. Also, recent
> mercurial has initial within-repo branches support. But I am not really
> the best person to conduct git-vs-hg discussion.

I'm glad that Mercurial is getting in-repo branches, they're great.  I really 
wouldn't want to live without them now I have them.

> > "(Note for Windows users: Mercurial is missing a merge program" - that
> > Windows support isn't looking quite so hot now.
>
> Mercurial on windows works well with kdiff3 or tortoisemerge, you must
> only install one of them.

Aren't they manual merge tools?  I think "merge" is for merging automatically, 
and moaning about conflicts if they turn up - /then/ you go to tortoisemerge.

> As I said, I am not conducting hg-vs-git discussion. I just happened
> to introduce and manage VC system in corporate environment, so I am able
> to point that this is important feature.

I appreciate that - I don't want to start a fight.  My point should probably 
have been more directly focussed on git (which was what I wanted to do) - 
it's my opinion that git is in fact easier than Mercurial; however, it's 
public face is not letting people see that.

> > As for permissions, well Shawn has often spoken of his hook scripts that
> > implement very strong permissions (and he has done so again in this
> > thread).
>
> I am not quite sure how can you forbid johny to see the code
> in ./secret, while johny must checkout whole repo...

Me either - the only permissions that could have been relevant are those 
needed to push to the central repository.  As I said, git can cope there 
without trouble.

> Permissions are not only about writing.

That one is true - perhaps one day git will get partial clone support to match 
it's shallow clones - then it would be possible to put permissions on the 
read of a central repository.  Can Mercurial do that?

> > Depends what you want - I installed cygwin
>
> This is really not an option for typical windows user. Believe me.
> Maybe it could be, if cygwin managed to create normal setup program
> one day...

I'm not an expert in Windows by any means - all I did was run setup.exe and 
picked git and ssh from the list.  It doesn't get much easier.

> Let me retype it: I am not complaining. GIT developers are not forced to
> think about win users, or about corporate needs. But if they are, it is
> reasonable to know the problems.

Absolutely - I certainly haven't taken anything you've written as a complaint.  
If anything I find it interesting because I think it confirms what I 
thought - git is not short on features or usability, it's just got a PR 
problem.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com