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

[Mathias Panzenböck]

On 05/27/2011 09:53 AM, GSR wrote:
> Hi,
> g.ulairi at gmail.com (2011-05-27 at 0929.04 +0600):
>> 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.
>
> Yep, total is>3.5GB: .git/ ~1.5GB, blender/<80MB, lib/ ~2GB. In some
> OSes, only blender/ and lib/tests/ are useful (<120MB, plus whatever
> .git would be). Anyway, git status is fast here... could it be one of
> those cases that depends in the OS or filesystem?
>

I was thinking: Maybe the blender repo should be split into several subrepos. Then lib (which 
contains a lot of binary files) could be shallow cloned by developers to reduce the download size. 
Maybe lib could even still stay a svn repo?

>> 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.
>
> Speaking of different habits or workflow, some of the git tools work
> better when using "git style". Take for example commit messages, first
> line is vital for some tools as it is used as summary in many
> places. Even commiting multiple topics as a single thing is
> disencouraged, and commiting to a tag is just impossible (in svn it
> works just because it is a branch, BTW). If you take other style,
> things work (or not), but you are going to expend too much time
> "fixing" the differences, and DVCS, everyone has to be own admin, so
> to speak. So the questions is if changing the software is worth if the
> methods stay the same.
>

The convention about commit messages is the same for hg.

> [...]
>> 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.
>
> As useful as the svn rev number, show what was used to create the
> binary. It can make older-newer checks impossible if no access to the
> repo, but otherwise a minor problem.
>
> GSR