On 02-11-2011 11:07, Denis Shelomovskij wrote:
02.11.2011 8:23, Caligo пишет:
I just found out that Bitbucket finally offers Git support. I wonder,
would anyone else like to see GDC switch to Git? I would like to kindly
make a request because it would make things little easier.
What things? I see, that every one switches to Git, but what the
purpose? I don't have a deep knowledge about DVCS-s, but I'm really
interested in what Git functionality is missing in Hg for you?
Is it:
* discarding previously pulled branches;
* pruning old revision data from the local repository;
* unlimited number of parent revisions during a merge;
* rebasing;
* infinite power of `git-push --force`?
Only the first one looks good for me, but the last one scares me because
you can loose the remote repository (and I really sow it frightens
people). Others are looking seldom applicable.
So why does Git advantages worth:
* Git complexity (in comparison with Hg);
* ability to loose the remote repository;
* lack of file rename/copy support;
* periodic maintenance with git-gc?
I don't hate Git. I just don't understand the current opinion and would
be glad if someone will base is for me, TIA.
Minor correction: Git does have rename/move support; see git mv. I do
not see why a VCS needs to be copy-aware.
I generally point people to http://whygitisbetterthanx.com/ when they
ask why Git is great, though personally these are the features I like:
1) Sane branching/tagging.
2) Better EOL handling (see core.autocrlf).
3) Rebasing.
4) Stashing.
5) Non-sacred history.
I'll elaborate:
1) Branching is pretty much the only way you can really screw up in Hg.
AFAIK, there still is no good way to revert an erroneous branch merge.
2) Hg requires setting up the win32text extension for this, while Git
simply asks that you set a configuration option.
3) This is absolutely essential in distributed development. When you
work on a large feature in a fork, you typically end up with lots of
commits. When you send this work upstream, you don't want to cause noise
in the history. Rebasing helps in avoiding this by squashing commits
together to get a nice, clean history.
4) I'm sure Hg has some similar command, but I really like Git's way of
using a stack for stashing.
5) Again, this is useful when doing distributed development mostly. As
you point out, rewriting history in the upstream repository _is_ a
really bad idea.
- Alex
