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
