Re: [Flightgear-devel] fgdata trouble
Thanks Thorsten for your clear words, yes, it sucks to see people messing up the history, merging local branches and then pushing them to gitorious. I personally see another problem in the way changes that are merged appear in the history: The merge date is there, but the commits associated to it can be hidden somewhere down in the history. This is a very bad state when it comes to bughunting (bisecting). Every fgdata contributor who creates complicated xml/shader files should be able to understand basic git workflow as well... Chris ThorstenB wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits >> have become duplicated and some undone (they exist in the history but >> their effect is gone from HEAD). > > It has happened again, fgdata history is messed up. It looks as if my > last commits (6d46fe7, f722671) were applied to fgdata multiple times > now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even > see how where these originated (looks as if I had pushed them multiple > times). Only the gitorious.org history shows that these were indeed not > pushed by me: > > https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 > > https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 > > Can we please make it a requirement that _local_ merge operations must > not become visible on our public repository, so _everyone_ has to > "rebase" before pushing anything? > > The only merge/branch operations that should be visible in our public > repo should be those that affect public branches (release branch > creation/merges etc). > > There's really no reason why other people should see that user XYZ has > merged his local branch 1-15 times with gitorious, before pushing back. > It only results in the git history becoming unreadable. And apparently > it results in more issues. > > If you compare simgear's or flightgear's history with fgdata's history, > you'll see how nice and readable a git history can be - since obviously > (almost) everyone pushing to sg/fg knows hows how to rebase. > > Resolving merge operations locally, to reorder and cleanup the history > is really simple - and only requires a few seconds. If you have > uncommited changes in your local directory, you can temporarily stash > them - so that "rebase" won't complain. > > For fgdata: > git stash > git rebase origin/master > git stash pop > > (And for simgear/flightgear: > git stash > git rebase origin/next > git stash pop > ) > > It is also a good idea to check the git history (gitk) before pushing to > gitorious: you can read and double check your own changes a final time - > and also check the history for local merge or funny duplication issues. > If you're having local Git trouble (like duplications), *please* ask > before pushing to gitorious. > > cheers, > Thorsten > > -- > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 2012-09-22 11:37, schrieb HB-GRAL: > Are there some plans to integrate some kind of a "webview" to the canvas > ? I remember there was some discussion about. Yes, this is definitely something I want to support. Maybe in a first step just a tiled map from files on the hard disk, but later also fetching from an url should be possible. It should also be possible instead of directly fetching the tiles from FlightGear just running an external application which puts the files in a folder where FlightGear finds them. > In case there comes a webview the mapserver could provide pre-drawed and > referenced tiles as images for a background and i.e. only the plane(s) > needs to be drawn. Common maptools on a server based on the same data > could be used (I’m using mapnik myself) and I guess one don’t need to be > online all the time with possibilities of subversion and/or offline > caching probably ? Just as an idea to save "drawing resources". I am also thinking about some kind of one-time canvas, where the contents are just rendered once and afterwards can be used in an other canvas as a texture and maybe even stored on the hard disk an reused the next time FlightGear is started up. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logitech force 3d pro hat question?
On Sat, Sep 22, 2012 at 9:17 PM, Ron Jensen wrote: > I use all custom bindings anyway. :) And in the current developer release you can change the orientation of the hat in-sim from the Joystick Configuration menu. -Stuart -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logitech force 3d pro hat question?
On Saturday 22 September 2012 14:04:10 Matevž Jekovec wrote: > Hi guys. > > I'm using Logitech force 3d joystick (force-3d-pro.xml) and the Y hat is > inversed. When I do hat up, it actually looks down and vice versa. Is > this the expected behaviour? Its personal preference, I think. I like the hat to follow the stick. Pushing forward looks down and pulling back looks up. I know this is reversed from some/many first-person shooter games, but as a long-time sim pilot it is much more intuitive for me this way. > I then changed two values from positive to negative of the view > elevation in the config and it works fine now. I attached the patch. > What do you think? I use all custom bindings anyway. :) Ron -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Logitech force 3d pro hat question?
Hi guys. I'm using Logitech force 3d joystick (force-3d-pro.xml) and the Y hat is inversed. When I do hat up, it actually looks down and vice versa. Is this the expected behaviour? I then changed two values from positive to negative of the view elevation in the config and it works fine now. I attached the patch. What do you think? Regards. Matevž Jekovec --- force-3d-pro.xml.orig 2012-09-22 22:01:48.0 +0200 +++ force-3d-pro.xml2012-09-22 21:53:43.0 +0200 @@ -112,7 +112,7 @@ property-adjust /sim/current-view/goal-pitch-offset-deg --2.0 +2.0 @@ -120,7 +120,7 @@ property-adjust /sim/current-view/goal-pitch-offset-deg -2.0 +-2.0 -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
"Alan Teeder" wrote: > New flightgear git users are faced with an initial download of about 10gb > just to get started. Currently the "fgdata" GIT repo has approx. 4.9 GByte, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport selection feedback
Am 21.09.12 22:45, schrieb Thomas Geymayer: > Am 2012-09-21 21:16, schrieb Stuart Buchanan: >> On Thu, Sep 20, 2012 at 11:44 PM, Thomas Geymayerwrote: >>> I've now changed the default fill rule from even-odd to non-zero. Should >>> probably work better now... >> >> Surprisingly, this didn't seem to make any difference. I've included >> the patch below >> if you want to check yourself. > > The problem was that ShivaVG simply hasn't implemented it :) I've now > extended ShivaVG to support some kind of a non-zero fill rule. It's not > really non-zero because instead of incrementing and decrementing > depending on the orientation of the drawn overlapping regions it simply > checks if at least a single region covers a pixel. For our use cases it > should be enough tough. > Hi Tom Are there some plans to integrate some kind of a "webview" to the canvas ? I remember there was some discussion about. In case there comes a webview the mapserver could provide pre-drawed and referenced tiles as images for a background and i.e. only the plane(s) needs to be drawn. Common maptools on a server based on the same data could be used (I’m using mapnik myself) and I guess one don’t need to be online all the time with possibilities of subversion and/or offline caching probably ? Just as an idea to save "drawing resources". -Yves -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata trouble
What happened to the work that went into breaking up fgdata into manageable chunks? New flightgear git users are faced with an initial download of about 10gb just to get started. It seems to me that this current problem is another good reason to re-arrange fgdata. So much work went into it last year, all to be scuppered by what seems to have been a unwillingness on the part of a few individuals to agree on the implementation. Alan -Original Message- From: Tim Moore Sent: Saturday, September 22, 2012 8:34 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] fgdata trouble On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits ... > It has happened again, fgdata history is messed up. It looks as if my > last commits (6d46fe7, f722671) were applied to fgdata multiple times > now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even > see how where these originated (looks as if I had pushed them multiple > times). Only the gitorious.org history shows that these were indeed not > pushed by me: > > https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 > > https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 > > Can we please make it a requirement that _local_ merge operations must > not become visible on our public repository, so _everyone_ has to > "rebase" before pushing anything? > > The only merge/branch operations that should be visible in our public > repo should be those that affect public branches (release branch > creation/merges etc). > I haven't looked at this latest problem in detail, but you can do as much damage rebasing as merging. I suspect the real problem here is rampant cherry-picking. I happen to think merging, at least when pushing local changes to the public tree, is a lot better than rebasing, because then a given set of changes only appears in a single commit in the repository. > There's really no reason why other people should see that user XYZ has > merged his local branch 1-15 times with gitorious, before pushing back. > It only results in the git history becoming unreadable. And apparently > it results in more issues. Yes, pushing a branch that has numerous merges from master/next is unpleasant. There are many pages on the Web describing git workflows that avoid rebasing and keep a clean history. > > If you compare simgear's or flightgear's history with fgdata's history, > you'll see how nice and readable a git history can be - since obviously > (almost) everyone pushing to sg/fg knows hows how to rebase. Except that I never rebase before pushing to sg/fg :) I should qualify that: I do interactively rebase before pushing, often rearranging commits and divying them up to make more sense. But I *never* rebase onto a different head than the one on which I started the branch. > > Resolving merge operations locally, to reorder and cleanup the history > is really simple - and only requires a few seconds. If you have > uncommited changes in your local directory, you can temporarily stash > them - so that "rebase" won't complain. > > For fgdata: > git stash > git rebase origin/master > git stash pop > > (And for simgear/flightgear: > git stash > git rebase origin/next > git stash pop > ) > > It is also a good idea to check the git history (gitk) before pushing to > gitorious: you can read and double check your own changes a final time - > and also check the history for local merge or funny duplication issues. > If you're having local Git trouble (like duplications), *please* ask > before pushing to gitorious. Can't argue with that. > > cheers, > Thorsten > > -- > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- How fast is your code? 3 out of 4 devs don\\\'t know ho
Re: [Flightgear-devel] fgdata trouble
On Fri, Sep 21, 2012 at 11:51 PM, ThorstenB wrote: > On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: >> The master branch of fgdata has become messed up. A number of commits ... > It has happened again, fgdata history is messed up. It looks as if my > last commits (6d46fe7, f722671) were applied to fgdata multiple times > now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even > see how where these originated (looks as if I had pushed them multiple > times). Only the gitorious.org history shows that these were indeed not > pushed by me: > > https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 > > https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 > > Can we please make it a requirement that _local_ merge operations must > not become visible on our public repository, so _everyone_ has to > "rebase" before pushing anything? > > The only merge/branch operations that should be visible in our public > repo should be those that affect public branches (release branch > creation/merges etc). > I haven't looked at this latest problem in detail, but you can do as much damage rebasing as merging. I suspect the real problem here is rampant cherry-picking. I happen to think merging, at least when pushing local changes to the public tree, is a lot better than rebasing, because then a given set of changes only appears in a single commit in the repository. > There's really no reason why other people should see that user XYZ has > merged his local branch 1-15 times with gitorious, before pushing back. > It only results in the git history becoming unreadable. And apparently > it results in more issues. Yes, pushing a branch that has numerous merges from master/next is unpleasant. There are many pages on the Web describing git workflows that avoid rebasing and keep a clean history. > > If you compare simgear's or flightgear's history with fgdata's history, > you'll see how nice and readable a git history can be - since obviously > (almost) everyone pushing to sg/fg knows hows how to rebase. Except that I never rebase before pushing to sg/fg :) I should qualify that: I do interactively rebase before pushing, often rearranging commits and divying them up to make more sense. But I *never* rebase onto a different head than the one on which I started the branch. > > Resolving merge operations locally, to reorder and cleanup the history > is really simple - and only requires a few seconds. If you have > uncommited changes in your local directory, you can temporarily stash > them - so that "rebase" won't complain. > > For fgdata: > git stash > git rebase origin/master > git stash pop > > (And for simgear/flightgear: > git stash > git rebase origin/next > git stash pop > ) > > It is also a good idea to check the git history (gitk) before pushing to > gitorious: you can read and double check your own changes a final time - > and also check the history for local merge or funny duplication issues. > If you're having local Git trouble (like duplications), *please* ask > before pushing to gitorious. Can't argue with that. > > cheers, > Thorsten > > -- > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
