> Every fgdata contributor who creates complicated xml/shader files should > be able to understand basic git workflow as well...
I'm not sure if you really mean every contributor, or every contributor with commit rights to FGData. In the second case I'd agree with you, but in case it's the first: I don't think GIT is particularly simple, nor have I found a good documentation. The basic tutorials / references which are human-readable are nice, but then all sorts of problems not covered in the tutorial crop up in reality. For instance, for some reason I can't push updates to my devel branch to my repo clone because of some timestamp issue, but remotely deleting and pushing new works fine. A rebase where the file a patch applies to has been deleted on master is a really good puzzle. And so on. On the other hand, the advanced manuals which would presumably treat these problems get into specialized nomenclature like alternative histories, octopus merging and what not and I can't find any understandable answers there. So in order to understand it on the level you seem to be expecting, I would really need to reserve a week and work through a long GIT reference book. Now, I'm certainly intellectually capable of doing so, it just doesn't make any sense to me. I can spend time only once, so I can either read 400 pages of real-time 3d rendering techniques and GLSL (which I find interesting and helps me to do what I want) or GIT (which I find boring and doesn't help me develop what I want). It's a no-brainer what I do. It's called specialization. In the physics department we work in, we have for instance administrative secretaries. So, whenever I spend money from my research grant, I don't know all the accounting codes for the various items, nor the procedures, they do. Of course the system could in theory be set up such as to require 60 physicists to learn accounting procedures and follow all the accounting rule changes, but it's been generally acknowledged that it's more efficient if the 4 secretaries do so, and the physicists focus on their business. Of course, you can be of the opionion 'Hey, if you want to contribute here, we require you to learn 'proper' GIT procedures' (whatever 'proper' is...). To which an alternative scenario would be 'If you want my contribution on your GIT server, you make it easy for me to get it there and don't make my jump through 10 hoops.' I think asking every contributor to properly work through a GIT manual before he can contribute is about as useful as to ask every contributor to learn the effects and GLSL framework before he can contribute anything - you're just reducing the not so large to begin with pool of contributors. In case of Nasal or shader problems, I usually try to step up and help with a fix if I can, because that's my speciality, I don't argue that everyone must know all Nasal tricks before he can contribute. I would hope that in case of GIT trouble, the GIT specialists step up. * Thorsten ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
