Is GIT limited to coding?
Status: Abandoned
Brought to you by:
mdbesten
Menu
▾
▴
#20 Is GIT limited to coding?
this "artefact" is not really related to the video in itself. It is just a stupid idea that generated random questions for the sole purpose of annoying you :)
If I'm not totally wrong, every file is a combination of code (hexadecimal or binary). As GIT is used to share code among developers, highlight modifications and merge the different versions of the code, I was wondering if GIT could be used for projects other than coding. For example, if you create an open source art project, would it be possible (natively or with a plugin) to use GIT to merge some parts of a drawing or a video? Would GIT understand what type of file it is managing? If no, would it still work as hexadecimal merging?
I tend to think that GIT could be used for more simple and less specialized tasks. If it was possible to manage an open source project rather than a development only, it could become broadly used and increase productivity in open source communities maybe by making it more accessible. It could also expand open source production to everybody
I don't know if i expressed my idea clearly enough. If not, just tell me i'll try to rephrase.
if i remember correctly (check with other engineer) the problem you will have with pictures and videos is that depending on the format, all the data is intricated at the same time for exemple in jpeg 2000(transformée en ondelette) you will have first the low frequency data, and then the data which have an higher frequency so if you just had something you can't just compare like you do with text..., same thing with the video, in mp4 the current image depends on what you previously had and on what you will have in the futur (used to compress the video) so the date will change (at least at the edges) if you put something in the middle and it won't be that simple... except if you define separate seuences of the video it might work this way
the coding scheme don't change anything hexadecimal or binary are just the way YOU see the data, for the computer it's always bytes (binary then) during the merging git will always ,by definition, merges bytes (the bytes of your files)
I think too that Git could be used for other things, but what i don't know yet
Je me posais la même question... (oui je parle en français). Pourquoi ne pas imaginer l’élaboration de maquette de projet par exemple (qui circule entre plusieurs services et donc plusieurs personnes) via ce procédé?
Je ne sais pas si ce système est possible. En tout cas l'idée est intéressante. Il est possible que les questions de format soient problématiques mais dans le cas de la Musique l'idée pourrait être sympa.
On peut facilement imaginer un système où quelqu'un propose un morceau de musique soit inachevé soit très basique et demandant aux autres participants de l'améliorer.
Certains ajouteraient un instrument sur toute la durée du morceau , d'autres ajouteraient simplement des percussions à quelques endroit ou des voix ponctuellement.
Les soucis de format sont ici contournés car les plages musicales peuvent se superposer à l'écoute.
ouais avec du midi ça doit surement marcher... pour d'autres format je sais pas, mais effectivement avec la musique c'est une bonne idée. par contre tu dois impérativement garder les pistes séparées si tu fais du wav ou du mp3 et ton résultat sera la fusion de tout mais si tu fais pas ça c'est pratiquement impossible de supprimer une piste par la suite (enfin il me semble)
See http://stackoverflow.com/questions/540535/managing-large-binary-files-with-git : Works with MP3, but not ideal.
Hello everybody!!
I don't know if what I will explain is also valid for Git, but it is like that for CVS and SVN.
When we work with code, we are working with the format ASCII. This means that the hexadecimal of the file is mapped on the letter of a the source code. So, to merge a code (in C, C++, Ada, Verilog, ...) it is the same process... To compare the hex and to show the differences.
To other kinds of hex, like files in work, excel, music, video, etc. the decoding is not so simple. It is necessary to understand more what the hex represents to decode and then to search another way to compare the files - another one than simple compare the hex. Well, maybe there are some specifics plugins, but i don't know.
What happens with text (ascii) in some VCS is that they only put on the database the difference between the versions and make some kind of link to recover the complete file when it is necessary. So, normally, when we "add" a new file on the repository we also indicate if the file is text or binary.
Talking about the community development of music, that exist! But with special software that is to compose music like that and where each one can contribute. There are also some particular studies for these kind of software. See: Otto Wüst, Sergi Jordà; Architectural Overview of a System for Collaborative Music Composition Over the Web.
it seems that it is possible to make music software devices with Git !!!!
Check this website : http://createdigitalmusic.com/2009/02/version-control-and-sharing-for-patching-keep-those-max-pd-patches-in-order-with-git/#more-5115
i will copy an extract here of what was written on the website :
Hi, I posted the first two parts of a three part series on why and how a version control system (git) can be relevant to musicians creating software devices for their music. The monome application-creating community and its use of max/msp form the case in point.SVN would work fine too.
Yes, Najate!
You can put the file that you want. And for the musicians it will be useful because they can have the versions. Where I worked, for example, we used to put binary files of power point presentations or documents in Word format. The problem is when we are talking about the merges, that it will be different from source codes and the kind of files that need a decoding. :)
For the article that you showed, I think that really it is not possible with Git: "If you have binary files, it’s going to be tougher to do things like merges — sorry, Reaktor.".