Hi Thorsten,
Renk Thorsten wrote:
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 meant the second case indeed.
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.
If you need help in a special case, there are always people here who are
glad to help.
In case of deleted files upstream that you want to rebase upon, yes that can
be a bit more difficult, but generally , if the file has been deleted it was
deleted for a reason.
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.
No need for that IMHO. You need to understand essentially 3 commands: git
pull --rebase, git rebase, git stash to do 90% of the work that you
will ever come along (not counting in commands like git log, git diff
and git status here, that are mainly for inspection purpose).
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.
So you are calling for git monkeys that take care of the tedious process
of getting changes into the tree?
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.'
Everyone is welcome to contribute, but yes, I request those people with
commit rights to have a good knowledge of what they do when pushing to the
repos. I don't mess with GLSL or Nasal code either if I have no clue what
I'm doing.
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.
The specialists would love to have the possibility to step up, but that's
only possible if they are asked *prior* to the push. Once the damage is done
in the repo, fixing it is possible, but would include a rewrite of the
history and that is not very much what anyone would like to do.
Chris
--
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
