Re: Revision control

[olafBuddenhagen]

Hi,

On Tue, Jun 03, 2008 at 09:10:01PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag 03 Juni 2008 05:16:47 schrieb olafBuddenhagen@gmx.net:

> > 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.
[...]
> 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,

You are missing the point. With git, *it is not necessary* to extend --
it's all there; git itself already allows doing pretty much anything
conceivable!

Of course, if you are doing something non-trivial repeatedly, you will
want to script it -- just like you would script any other repeated
non-trivial action on UNIX...

git-stash is a nice example of something that -- if it wasn't already
provided by default -- could be easily done by hand or by simple
custom scripts.

> 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, 

Which isn't surprising at all. git-checkout by default preserves local
changes; and deleting a file is a change. "git-checkout -f" on the other
hand would probably do what you want -- and a short look in the man page
should tell you that.

> 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... 

Actually, the command was probably "git-checkout-index -a", which still
works. It does something slightly different than "git-checkout -f" or
"git-checkout .": It checks out deleted files, but doesn't overwrite
modified ones.

> With a bit of dabbling I just found out how it can be done, now: 
> 
> $ git checkout .

This actually runs "git-checkout-index -f -a", which is very similar to
"git-checkout -f", except that it doesn't sync from repository to index
before checking out the index. In other words, it has a different effect
if you did git-add or something like that earlier.

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

Actually, it does a bit more than only printing the status. It just
happens in this specific situation that it has no other visible
effect... I suggest reading the man page :-)

> If I pass files, it updates them instead. 
> 
> And that doesn't feel natural to me. 

I agree that it's somewhat confusing that git-checkout behaves
differently when given file names, than it does without file names. This
also happens with some other high-level git commands.

Anyways, it's generally known that the git UI is not as polished as
Mercurial; nobody will deny that. However, when I decided to learn git
is spite of that (knowing that it has other advantages), I found that it
is in fact not nearly as bad as its reputation. (Not anymore at least...
Newer versions improved quite a bit from what I hear.)

My experience (from what I saw in Xorg) is that people having *serious*
problems with git usage (i.e. problems that can't be solved by looking
at the man page(s) for a moment), are generally a result of not
bothering to understand the basic concepts of git. This is just as
appropriate as complaining about UNIX usability without understanding
UNIX concepts...

I'm not claiming that git is perfect. I'm only saying that learning to
use git is worth a bit of trouble IMHO. I just can't agree that we
should always go for the simpler tool, if the more powerful one is
harder to handle at first...

-antrik-