Re: [Flightgear-devel] urgent git help requested
Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. If you've pushed a commit to a public repo and then it later turns out that the commit wasn't a good idea, then you want git revert which creates the reverse patch for a given commit. However, if you make a real hash out of a public repo you may still want git reset. Tim On Tue, Feb 8, 2011 at 8:04 PM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 8 Feb 2011, Curtis Olson wrote: I made a commit into a branch of a --local clone of my fgdata repository. I pushed that to the matching branch in my main fgdata.git repository. Then I attempted to merge one commit into the master branch ... however it merged *all* my changes. How can I back this out (I've made some hacks to some f-14b nasal files which are intended for personal expermentation and break standard behavior.) How can I cherry pick one particular commit to merge into the master branch? Backing it out might be a bit tricky, but you can rename your messed up branch out of the way easily with git branch -m oldname newname. To cherry-pick commits from your other repository into a branch you first fetch the branch you want to pick, e.g. git fetch theOtherRepro.git theotherbranch:suitableName/theotherbranch Or just theotherbranch:suitableOthername Then you can inspect the commits on it with git log -u theOtherRepro/theotherbranch And finally cherry-pick the one you want with git cherry pick commitID I always use a clean local copy (e.g. git branch -t mrClean origin/master) of origin/master to cherry-pick commits to before pushing to origin. I leave that branch around since the next time I just need to check it out, do git pull which will be a clean fast forward and cherry-pick and push again. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On 02/08/2011 11:04 AM, Anders Gidenstam wrote: Backing it out might be a bit tricky, but you can rename your messed up branch out of the way easily with git branch -m oldname newname. It's worth experimenting with git reflog in situations like this. That tracks a list of HEAD references in strict chronological order (i.e. what has HEAD been in the past, not what commits were done). In cases where you've completely mucked up the revision history, you can look at this to see what you were doing before, recover the commit ID, and do a reset --hard to that. Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On 02/09/2011 12:02 AM, Tim Moore wrote: Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. Actually, unless I've misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to before the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
What I did was run a git merge when I really wanted to do a git cherry-pick. The merge merged everything in my test branch, and I just wanted the one single commit moved over. I haven't done enough of this yet to have remembered the difference. Most of the time (but not always) git seems to know when I'm screwing something up and doesn't let me do it. Which is a good thing because it's been a lot of trial and error figuring things out. Off the top of my head I was able to use a combination of git log and git status to figure out the sha-sum of the most recent commit that didn't involve my own screw ups. I then ran the command: git reset --hard d1dbc6739fcba19956b6e2cae1fdd4975be392d4 And then git log and git status appeared correct and didn't seem to reflect any of my mistakes, git pull reported completely in sync with the gitorious repository. The using a combination of git log and status I figured out the exact sha-sum of the specific commit I wanted to merge and ran: git cherry-pick f4efd11fbb3af9513b51918026188d1fd6f00fd5 That did the trick (cleaned up my mess and performed the task I originally meant to perform.) Finally I did a 'git push' to send the change upstream to gitorious. Thanks for all the advice ... some if it I understand, and some of it I don't. :-) Curt. On Wed, Feb 9, 2011 at 12:49 PM, Andy Ross wrote: On 02/09/2011 12:02 AM, Tim Moore wrote: Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. Actually, unless I've misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to before the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sinking feeling - c172 on gravel runway
Hi all, When putting the default c172p on a 'gravel' runway, like say YGIL:33, after a number of seconds the aircraft 'tilts' slowly backwards... And it will also happen on a reset... and can happen after applying heavy breaking on the gravel. And there seems no particularly relevant output to the console when it happens... It is very hard to get a good view of it, but in studying what I can, it looks like maybe the two rear wheel 'sink' into the gravel, while the (nasal controlled, I think) front wheel either just touches the surface, or even comes to rests 'above' the surface. While the tail of the a/c sinks down, the tail does not appear to actually touch the ground - I suppose about a 5 degree nose up attitude... I have never seen this on other runway surfaces... even on the default YGIL:08 which is 'Dirt'! Starting the motor, and moving forward a few feet will right the plane - bring it back to an even keel... if you are careful with the brakes... It looks like the nasal that controls the front wishbone type suspension, is over straightening the wishbones, for some reason, but not sure... especially when it looks like the wheel is above the surface... When in the 'normal' flat position, the black wishbones look to be at about 60 degrees, while in the tilt-back state, it looks closer to 90 degrees! Perhaps the best screen shot is this one - http://geoffair.net/tmp/tilted-001.png and this is after moving forward... http://geoffair.net/tmp/tilted-002.png back to level... And it does not happen if I drive the plane off the gravel onto the grass beside the runway, so it does seem related to the 'gravel' runway surface. http://geoffair.net/tmp/tilted-003.png This started some time back, I think around the time of the last JSBSim sync... but not sure. I do not think it was in 2.0 for example, but will recheck this... It happens in both my own Ubuntu build, from a recent git 2.2.++ update, and in Fred's WIN32 setup 20110207.exe, where the above images were taken. (Fred, thanks for a great simple WIN32 installer by the way ;=), and the terrasync pre-fetch is fantastic!) The only likely place I can find is in c172p/nasal/action-sim.nas, where it comments # Compute the scissor link angles due to \ nose strut compression which looks to be the problem, but have not tried changing anything, mainly through lack of understanding on what is done here... especially how the type of 'surface' comes into it... Not really a 'big' problem, but quite annoying just the same... it makes the Cessna feel like a tail dragger ;=)), but as mentioned, the tail does not actually touch the ground. You can not see if any kangaroos are crossing in front of you... Any help to get the plane to rest 'properly' on this gravel surface would be much appreciated. Regards, Geoff. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
Geoff McLane wrote: I have never seen this on other runway surfaces... even on the default YGIL:08 which is 'Dirt'! I have seen this on various asphalt runways as well, I think it's a general issue with the current state of the C172. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] urgent git help requested
On Wed, Feb 9, 2011 at 7:49 PM, Andy Ross a...@plausible.org wrote: On 02/09/2011 12:02 AM, Tim Moore wrote: Backing out is done with git reset --hard last_good_commit. Often the name of the last good commit is HEAD^, the last commit. However, after a botched merge it is good to verify that with git log or graphically with gitk. I should have said HEAD^ is the previous commit on the current branch. I believe this is the case in the absence of exotic options to git merge. Actually, unless I've misunderstood your point, this won't work: the commit history following a merge is an interleaved mix of two branches. You can't just walk back to before the merge. Doing that gets to to the equivalent of git merge-base, which is the last version that includes *none* of the changes in *either* branch. A merge commit has two parent commits (leaving aside octopus commits). If you are not happy with the results of the merge, usually you want to revert back to the parent that was on your branch. As you say, the reflog can be useful for checking this, but usually the parent of the botched merge on your branch is HEAD^. I'm not sure what you mean by the history is an interleaved mix of two branches. git log shows the commits in reverse chronological order by default, but the parent-child relationships of the commits in the two branches is definitely preserved. Tim I don't think that's what Curt wants. See my comment to Anders about git reflog. (and yes, I've made exactly this mistake in the past, heh) Andy -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Near Clipping in the virtual cockpit: please help!!
Hello! I have unsolved problem driving me nuts for weeks now. In my opengl application the terrain presentation is flickering very frequently (either as whole our 1/3 of all polygons). The problem disappears as soon as i increase the near clipping value. The problem root is the z buffer precision, but greater near clipping in turn truncates much of the virtual cockpit display. How did you solve the clipping problem in flight gear??? Thanks in advance Paul -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] terrasync.cxx diff for FreeBSD
Hi all, I have just finished building the releases/2.2.0 branch on
FreeBSD-8.1.
Please apply this diff for a successful build :-)
diff --git a/utils/TerraSync/terrasync.cxx b/utils/TerraSync/terrasync.cxx
index f1a2cc4..d15078d 100644
--- a/utils/TerraSync/terrasync.cxx
+++ b/utils/TerraSync/terrasync.cxx
@@ -290,7 +290,7 @@ void sync_tree(const char* dir) {
#if defined(_MSC_VER) || defined(__MINGW32__)
typedef void (__cdecl * sighandler_t)(int);
-#elif defined( __APPLE__ )
+#elif defined( __APPLE__ ) || defined (__FreeBSD__)
typedef sig_t sighandler_t;
#endif
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
