Re: Revision control

[Arne Babenhauserheide]

Sorry for the double-posting. I hit send by accident. 

Am Dienstag 03 Juni 2008 05:16:47 schrieb olafBuddenhagen@gmx.net:
> How accessible it is, depends first and foremost on what most people
> know. That probably leaves Mercurial and git as the only serious
> contenders...

That's right. 

And after that it depends on the fact how easy it is to learn it from the 
things most people know. 

And as far as I know, if you can use SVN, you can use the basics of Mercurial 
after about 5 minutes, that means: 
- Before you update, run "hg pull". 
- To publish your changes, run "hg push". 

If Mercurial prints a warning with a hint what to do, check if you're certain 
you want to do the action, and then just do what it says in the hint (for 
example running "hg push -C" to create a foreign head). 

> Not knowing Mercurial, I can't really judge. But I have a very hard time
> believing that any other system comes even *close* to the power and
> flexibility of git... git is not a shiny toy with idiot-proof UI; it's a
> powerful tool for serious users.

I would say, that depends on who you see as "serious user". 

(everything above is my personal opinion and is sure to be be biased by my own 
experience). 

If you mean someone who wants a tool that does the job of managing a 
distributed repository and can be extended very well, then Mercurial and git 
should be quite equal for him, as long as he doesn't care about the time 
needed to learn the tool, and about some mistakes which might take some time 
to fix in the beginning. 

If you mean someone who wants to explore every corner-case, no matter the 
complexity, then git wins for him in some cases (cherrypicking is still 
better in git, branches are still more lightweight, and it has some plugins 
which aren't avaible in Mercurial). 

If you mean someone, who wants a tool which does the job of managing 
distributed repositories while having a low maintenance overhead as well as 
making it easy to do advanced stuff, then Mercurial wins (in my experience). 

For case that I have a personal experience from a few months ago: 

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- 
----- ----- 
I had just cloned a git repository and deleted some files. I thought

"No big deal, it's a git repository, I'll just tell git to get them back."

Which then sent me on a safari through google and manpages. 


$ git checkout

didn't work, 

$ git checkout name1 name2 name3

would have done it, but I couldn't give the names of the files, since I didn't 
remember every file I had deleted. 

Google didn't help me, and the man page didn't either. 

After half an hour of searching I gave up, deleted the repository and cloned 
it again to get the files back. 


Two weeks later I told that story to a friend who knows git from heart. His 
answer was: "just do

$ git checkout -a

and you have it". 

Quite simple, but I didn't find that in half an hour with google and man 
pages. 
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- 
----- ----- 

And it doesn't work anymore... 

Today "git checkout" returns a list of deleted files, which I can't even pass 
to git checkout directly in a pipe. 

$ git help -a

is still used to return all help items, though. 


With a bit of dabbling I just found out how it can be done, now: 

$ git checkout .

because I have to explicitely pass the files I want to checkout, and the 
current dir counts as file. 

If I don't pass any files to, it returns the status of all files. 
If I pass files, it updates them instead. 

And that doesn't feel natural to me. 
It rather feels like sacrifycing usability for looking powerful. 

Or like working without clear vision (or without clear enough usability 
vision). 

As another example, I miss simple shorthands like "git co" for checkout. 
(I know you can define them yourself, but why aren't they shipped with git out 
of the box, when most people will create them anyway after some time?) 

Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.