Blender Switching to Git (from SVN)

General Forums Blender and CG Discussions
#1

I have been watching the latest videos from the Blender Conference on the Blender Foundation Youtube channel. It was very exciting to hear that blender may be moving to Git as a source control solution. So, I thought I’d start a thread here to gauge peoples opinions and thoughts on the matter. I’ll go first, I suppose:

I work in web development and design (among many other similar fields) and therefore have a need for source control/versioning in my projects, both production and personal ones. Having made the switch from Subversion to Git, I can attest to the dramatic efficiency increase when working in a team environment. As I said, I’m excited for what it could mean for blender. That octocat really knows his stuff when it comes to merging (up to eight-way merge–though I’ve never tried that). :wink:

#2

For me on windows, this is horrible news.

I am still investigating on how to use Mercurial (tortoiseHg) with a git server. Does anyone have some experience with this?

#3

Are you just in need of an effective git client? git-scm.com has a list of clients for windows on their website here: http://git-scm.com/downloads/guis Check 'em out, I bet you can find something that works very well. SourceTree looks pretty inviting to me, though I’d not use windows for any active development unless forced to. GitEye seems more aesthetic to me from the screenshots.

#4

Git is super simple on Windows! Not sure what the holdup is.

#5

TortoiseGit on windows is simple to use. Just like tortoiseSVN, but with more.

#6

TortoiseGit has been working for me for a few years already as well.

#7

Personally, I just use msysgit (git-gui + git bash, combined with “git-cheetah” context menu thing) on Windows, and install the equivalent packages on Linux (though I still miss a git-cheetah equivalent for Nemo, and built-in antiword plugin when diffing word docs).

I’ve been using this setup nearly exclusively for all my uni projects (mostly py codebases, latex reports, and a few collections of Word docs) and/or any other new side development projects I work on (e.g. depsgraph refactor project) for the past 2-3 years now, where it works really well. I think I only keep svn around now to keep committing to Blender and/or grabbing some legacy projects from some other places, but never for any new projects.

Anyways, I can’t wait to start being able to develop blender with proper branches which don’t suck (when you try to perform any merges with them)!

#8

So what would guys figure is the main advantage of GIT over SVN? It’s flexibility?

I used both, but when using SVN I was directed by other people into using and had no real idea what I was doing(besides commiting) and GIT I used on personal projects, so I had a better idea of what I was doing, but that also means I’m more fond of GIT for understanding it better.

From what I understand it’s much cheaper to branch, which I imagine is pretty welcome. But I hadn’t heard that merging branches was simpler as well.

#9

Git’s main advantages IMO are:

  1. The ability to commit a whole bunch of stuff locally (and potentially while your internet connection has gone down again for whatever reason), meaning that with larger projects (i.e. refactors of certain things) you don’t end up in situations where you’re effectively lugging around this huge set of changes in your working directory (or in various patches) while carefully skirting around the edges hoping that you don’t accidentally end up completely destroying something else you’d fixed earlier but hadn’t committed as the project wasn’t complete but the refactor itself was also not large enough to justify creating an official branch on the server (and all the merge overhead/responsibilities you get what that too)

  2. Related to this ability to perform local commits is that ability to simply mark and lobb-off a failed attempt using some tag/branch (in case you change your mind again another time), then simply reset the tip of the development to an earlier point before you started your failed experiment, and carry on working from that old commit again as per normal. You can even do this multiple times when you’ve got multiple conflicting directions going on at once (though it does admittedly get tricky keeping tabs on all of these activities by this stage).

  3. The whole staging'' process, and the benefits that gives you for masking off different features you may have needed to implement together in the same file but which you want to commit separately. Or perhaps there are some changes in some files that you don't want to commit externally. Finally, as others have noted in various threads about this, it's a really nice safety valve to have when using blunt-forcereplace all’’ tools to give you one added layer of security/last chance of veto for potentially dangerous changes which may have slipped through the cracks

  4. Merges in general are fast, and for the large part, much cleaner (conflict wise) than SVN (namely because you don’t need to wait 3-6 hours to see if you accidentally ended up getting the revision ranges wrong).

Non-Advantages:

  1. Merge conflicts still happen. That’s a fact of collaborative editing life (even when it’s you against yourself working on another feature from a few days ago)! At the end of the day, nothing quite beats simply firing up your text editor, searching for ‘<<<’ , and muning the conflicting code by hand

  2. Mandatory commit messages. It depends on what your standpoint on this is, but we can generally agree that commits with no info about what they’re about, especially in larger teams is just irresponsible/unprofessional behaviour. Of course, this can sometimes be a pain when in a rush.

  3. More complicated conceptual model for how your interact with the version control system and various repositories. Unlike SVN, I’m not that fond of trying to explain all the relevant concepts here. Particularly nasty are the schenanigans surrounding “tracking branches” vs “remote branches” and getting them to sync up/attach correctly by default.

  4. Revision numbers vs hashes - TBH, SVN’s revision numbers are a really nice and simple concept to have when distributing regular rolling releases to a wide community of users, making it really easy to tell whether a user is up to date or not. Hashes on the other hand are simply not something that most human beings are really well adapted to working with - sure we can compare them, but we are dead slow at it and frequently make mistakes. Then again, in ``the Git way’’, you practically don’t really want to ever directly manipulate things via these hashes as your references. It’s much better to use a competent GUI tool here, as sooner or later you’ll get into a situation where you’ve accidentally managed to commit stuff you didn’t intend to commit, which you can either not remove now wtihout also accidentally clobbering some other parts of your history. Oops!

#10

Oh, and I forgot to mention there: yes, flexibility in terms of how you want to structure your workflow is a very big part of it.

On several occasions, I’ve used a “fork the tree from point a, create a number of alternatives - b, c, d - in separate branches off a, and quickly switch between these to compare which one works the best” workflow. The alternative of course would have been to include these switches in the code, and hence, end up confusing yourself which parts belong to which version :slight_smile:

#11

Merging, in any SCS, amounts most of the time to decide who is going to redo his job almost from scratch (unless you work with highly modular systems).

People keep complaining about hashes in Git: one of the first things you learn when using Git is that you can assign tags to commit, you can change them after the fact, you can have as many tags on a commit as you like and you can freely delete them afterwards so, if you have even the slightest though that you might be interested in going back to a specific commit, just tag it. Instead of saying revision 60644 is the build point, you just add a blender_269_rc3 to the specific commit and that’s that (people have just to get blender_269_rc3 and build it). And there are (horror!!!) “graphic tools” (nah, only Micro$erfs use graphic tools) to manage the branch/forest.

The real advantage of Git? everybody has a nearly complete story of the project so when disaster strikes, the person with the most up to date local repository pushes it to the reconstructed/relocated central server and work can restart.

#12

That’s exactly the kind of attitude that’s keeping Linux from the Desktop. Linux developers do not properly value graphical user interfaces. That’s why debugging on Linux feels like going back into the stone age of computing.

I for one don’t see any benefit of Git that warrants its drawbacks as a non-native application, consisting of dozens of unix commandline tools, compared to Mercurial that runs elegantly and natively on Windows and provides a native Python interface.

#13

There is no need to install all the Msys crap on Windows, you can use TortoiseGit or Eclipse (fairly good integration with Git) or Netbeans (nearly seamless integration); Eclipse and Netbeans double also as good IDEs for C/C++ development.

P.S.: in case it did not get thru, my comment on graphic tools was a sarcastic mocking on penguinistas attitude. For my daily Java2EE development work I use Eclipse and sometimes Netbeans and go to the command line once or twice per week. The command line is a thing penguinistas use to show off that they are more skilled than the others (while the others are not showing off but working).

#14

For my own workflow, git support in qtcreator, which includes visual diffing (with colors yeiii!), logs, branches etc is really nice to have. But then again git is not really THAT hard to grasp on the console either.

#15

There is no clean solution on windows on how to install git. You always have to install msysgit.

Git for Windows is required by TortoiseGit (sometimes also mentioned as msysGit)

With mercurial you got a nice native client.

And please don’t start comparing the wanna-be TortoiseGit with the full blown native client TortoiseHg :smiley:

But I just want to ask again: Does anyone got experiece using a hg client with a git server?

#16

This doesn’t make sense.

Also I don’t usnerstand what the problem with git on Windows ist (considering that apparently people use git at Microsoft).

#17

To those pushing back against git, keep in mind that the sheer size of the Blender project in terms of the number of branches and commits is starting to outgrow the capabilities of a linear versioning system such as SVN. To ensure that development stays smooth, the devs. have decided it is time to move into a distributed system that can handle many branches of development at once and ensure less in the way of error when many commits are being made.

Heck, there’s some developers who already have private git branches of Blender, and the variant that Blender will be using will be one of the nicer ones that allows for more tailoring specific to the Blender project. It seems like the pros here may very well far outweigh the cons.

#18

Also, Git is decentralized, which is exactly the way open source development is meant to be done… No more “commit rights”, instead - network of trust.

#19

Well, even with subversion you could still have a working copy and set up your own repository, but Git is certainly better designed for (easier) decentralized development.

Ultimately, I’d expect there will be someone/some people managing the master and determining which pull requests to allow, what to merge, etc.

#20

I’m not saying Git on Windows is necessarily a problem, I want to know why people automatically jump to an ugly unix/perl-based toolkit instead of a clean native program, when they’re developing a cross-platform application? What makes Git superior?

To those pushing back against git, keep in mind that the sheer size of the Blender project in terms of the number of branches and commits is starting to outgrow the capabilities of a linear versioning system such as SVN.

That doesn’t mean you have to use Git. Mercurial essentially solves the same problems.