Can I use git to replay changes for projects that use media assets rather than program source code?

Question

So while waiting for a project to build I like to run gource and see a fun video of my team building the project over time. While I was watching me and my team fly around editing and changing the file tree a coworker who is on our media team loved the visual representation and immediately asked how I could do this for his team's media projects ( documentaries, short videos, poster design projects ) which are worked on as a team and everyone edits files individually and then pushes them up to a central server on the LAN.

I know git would freak every file change because to it the entire file is new every time they say export the video to the LAN or anything like that. But would a quick git repo be possible for a media team? How much overhead vs pay off would they expect?

Answer 1

Git is not very will suited for this as evidenced by the fact that currently at least three different extensions exist to handle this problem git-fat, git-annex, git-media.

Svn also have the possibility to only check out only a sub folder of the repository which git was explicitly designed to NOT to do.

Since git is distributed all clones must contain all versions of all blobs which will be large for binary files since they don't compress or diff well. Svn is centralized so a checkout can checkout only the recent version.

I recommend using svn or using one of the git extensions.

Answer 2

Pro and Cons:

For:

• will store different versions over time
• will still be able to use compression to reduce file size for older versions.
• will enable different developers to share one code (or asset in this case) base.
• will make sure any common files stay with 1 version.
• will track who touches which files.
• can use the git-fat tool https://github.com/jedbrown/git-fat to not store the files in git but use $ git fat pull when you want to get one
• will be the same tool that many people will already know form using it for code.

Against:

• different versions of media assets will probably need to be stored in their (compressed) entirety.
• standard 'git difference' functionality will not work on media which is not code without customization.
• people will need training in at least a subset of git commands and/or a git gui
• will require all users to get all files, which for media, can mean a huge amount of data

The last point, also mentioned by Esben Skov Pedersen, is possibly a good reason to use SVN for the media. This would be a judgement call. With SVN you get the huge advantage of being able to get individual files and directories instead of the complete repository as with git. The downside is that its an older technology with some different philosophies and and if folks use git at all (either concurrently or at other times) they will find the different philosophies and different syntax (or, worst, same syntax, different meaning!) confusing.