[Bf-committers] Let us switch to git, pretty please

Mathias Panzenböck grosser.meister.morti at gmx.net
Fri May 27 07:02:20 CEST 2011


As long time bf-committers reader who has committed one or two tiny patches in the past I like to add:

Pros for HG:
More intuitive to use, especially things like revert.
Nicely extensible using Python (e.g. generic keyring integration for repo passwords).
TortoiseHg > TortoiseGit and cross platform (Qt based).

Pros for GIT:
The SVN bridge seems to be much faster and transfers less data than HGs SVN bridge (last time I tried).
Some people like this staging thing much. Never used it.
It is said that a repo with many very different branches is smaller in GIT.
github/gitourios > bitbucket (but bitbucket is ok)

Many things are possible in both, but the defaults differ. E.g. in HG you have to enable several 
extensions (that are included, just not enabled) to get things like paging+colors on the shell, 
rebase, squash (which isn't called like that in HG, I think) etc. But then in HG there is a built in 
webserver (`hg serve`) that supports pushes (if enabled)! It can also be hooked as CGI script with 
about two lines of Python code. But currently HG only supports Python 2.x.

(I somehow like HG better.)

	-panzi

On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote:
>    Hi,
>
> I'm not sure switching the whole repo to git is a nice idea. Last time
> i've checked this it was very painful to work with libs/ repo cloned
> with git -- simple `git status` used to work ages. Maybe this is because
> of plenty of binary files, not sure. And size of that local cloned repo
> was also incredible big -- several gigabutes, iirc.
>
> Git for codebase works really nice when you've got plenty of branches --
> no pain with all this re-branching and so. Simple `git rebase` and here
> we go. There's also advantage for releases -- tagging happens much nicer
> with git.
>
> It'll be also more useful for pre-realse periods while codebase is
> frozen -- developers could still commit features to the development
> branch, but they wouldn't go to master.
>
> About clients i could say that git on linux works nice, msysgit works
> fine for windows. There's also TortoiseGIT. I haven't used it much, but
> it worked also nice. But i have to admit, that some firends of mine had
> some occasional troubles with it.
>
> P.S. as one more disadvantage, we'll be unable to have that r<number>  in
> splash screen. It could be short commit SHA, but not sure it'll be useful.
>
> Tom M wrote:
>> It was discussed a bit yesterday on irc as Jason was updating his
>> sculpt branch to head that it would haven been much less pain with GIT
>> potentially.
>>
>> Brecht and Ideasman and other core maintainers what are your views on
>> moving to git or mercury?
>>
>> Ultimately the decision will be up to Ton of course, but would be good
>> to get a straw poll on sentiment for it.
>>
>> LetterRip
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>



More information about the Bf-committers mailing list