BitBucket Offers Git Support

[Alex Rønne Petersen]

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