Hello Anders,
Thanks for the quick reply, yes we had some sync issue with our Git.
right now that's OK
Kind regards,
Ahmad
On 14 October 2013 14:15, Anders Gidenstam wrote:
> On Mon, 14 Oct 2013, grtuxhangar team wrote:
>
> Hello,
>>
>> with FG 2.99 Data i am getting
>>
>> Nasal runtime e
On Mon, 14 Oct 2013, grtuxhangar team wrote:
Hello,
with FG 2.99 Data i am getting
Nasal runtime error: No such member: asin
at /devel/fgdata_git/Nasal/geo.nas, line 173
called from: /devel/fgdata_git/Nasal/view.nas, line 306
called from: /devel/fgdata_git/Nasal/view.nas, line 265
called
On Thu, Aug 9, 2012 at 11:50 AM, Tim Moore wrote:
> If you are going to keep a branch for a long time that you are not
> merging back into e.g., master, there are a couple of possibilities.
> One is to merge (pull) master into your branch. Another is to check
> out git-rerere (I kid you not), whi
On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch. So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase. I think
On 08/09/2012 07:45 AM, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch.
Not true in general. I've never had a problem like that.
> So even if I figure out a way through
> it once, I'll have to repeat the same c
On Thu, Aug 9, 2012 at 10:44 AM, Anders Gidenstam
wrote:
> If you can figure out which commits cause the problems you can edit them
> out of your branch (or, better, out of a copy of it) using
>
> git rebase -i HEAD~42
>
> (change 42 to the number of commits back from HEAD that you need to
> touch
On Thu, 9 Aug 2012, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch. So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase. I think I'm going t
It looks like every time you rebase you have to reapply the same set of
patches over top the target branch. So even if I figure out a way through
it once, I'll have to repeat the same conconction of craziness each time I
rebase. I think I'm going to create a new branch, untar my changes on top,
l
> The typical fix is to edit the conflicting files and "git add" them the run
> "git rebase --continue".
> But these files don't exist so I can't edit them, git add fails, git rm also
> fails since they don't exist.
If the files no longer exist, I think one solution is to tell the system to
s
On Wed, Aug 8, 2012 at 12:06 PM, Tim Moore wrote:
> It sounds like your local tree has not been completely committed. See
> what "git status" says. Check out the man page for git-mv. I can't say
> more right at the moment, but I'll see if I can add more details
> later.
>
There are a couple other
It sounds like your local tree has not been completely committed. See
what "git status" says. Check out the man page for git-mv. I can't say
more right at the moment, but I'll see if I can add more details
later.
Tim
On Wed, Aug 8, 2012 at 5:45 PM, Curtis Olson wrote:
> A quick update here. Rob
On Wed, Aug 8, 2012 at 10:45 AM, Curtis Olson wrote:
> A quick update here. Rob pointed out the "git rebase --abort" command
> which got me back to a sensible working state. I was able to reevaluate my
> original problem which turned out to be a simple merge conflict in my
> branch vs. changes
A quick update here. Rob pointed out the "git rebase --abort" command
which got me back to a sensible working state. I was able to reevaluate my
original problem which turned out to be a simple merge conflict in my
branch vs. changes in "master" and I was able to fix that and successfully
merge -
On 25 Apr 2012, at 07:04, Renk Thorsten wrote:
> A quick 3 minute test flight with the ufo looks very promising - I didn't see
> any obvious issues with the version pulled 10 minutes ago. I will do longer
> tests later toady.
Thanks Thorsten!
James
--
> What about the mentioned problems? Better? Worse?
A quick 3 minute test flight with the ufo looks very promising - I didn't see
any obvious issues with the version pulled 10 minutes ago. I will do longer
tests later toady.
* Thorsten
---
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
> Okay, I guess I was assuming I can use SGreferenced the same way I use
> release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
> this is not the case, from looking at your commit - I can't use
> SGreferenced as a v
On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote:
> I could by the length of the thread not exactly find what is going wrong and
> how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I
> can see that this does not match the intented use of SGReferenced.
> I have checked in
Hi,
On Tuesday, April 24, 2012 13:39:59 James Turner wrote:
> Okay, then I realise this isn't useful for you, but I'm stumped why it
> crashes for you. In particular, the hashForAirport function is being passed
> something that looks like a valid pointer (I think), and it crashing on a
> line tha
James,
I wasn't affected by a crash until I realized that hashForAirport was never
called. Then I enabled animated jetways and the segfault came, after few
successful calls.
I am not able to tell why though
HTH
-Fred
-
Im assuming my crash is related, but it only happens when i open the
route-manager dialog...
Syd
On Tue, Apr 24, 2012 at 10:24 AM, Curtis Olson wrote:
> On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
>>
>>
>> As far as the FGPositioned Octree is concerned (which is what findClosest
>> use
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
>
> As far as the FGPositioned Octree is concerned (which is what findClosest
> uses internally), it's holding an owning ref and hence things can't be
> removed from it, for the moment.
>
> So what I guess is happening, is that I'm breaking th
On 24 Apr 2012, at 16:50, Curtis Olson wrote:
> If an FGAirport object was ref-counted and deleted because the ref-count went
> to zero, then why would FGAirport::findClosest() still be returning a
> pointer to it it as the closest airport? Is it not getting fully/properly
> deleted or remov
Hi James,
just a guess here, but in the past, I had to fix issues brought when converting
raw pointers to smart pointers and ending up deleting the pointer given by the
smart pointer explicitly. For example :
SGSharedPtr myPtr = new MyClass;
then
delete myPtr;
or
delete myPtr.get();
afterwar
On Tue, Apr 24, 2012 at 10:35 AM, James Turner wrote:
>
> On 24 Apr 2012, at 16:31, Curtis Olson wrote:
>
> > Based on two runs with out crashing, that seems to prevent the crash ...
>
> Okay, so that's good but leaves me wondering why it doesn't crash on
> Mac the same way. And also, how I'
On 24 Apr 2012, at 16:31, Curtis Olson wrote:
> Based on two runs with out crashing, that seems to prevent the crash ...
Okay, so that's good but leaves me wondering why it doesn't crash on Mac
the same way. And also, how I've got the ref-counting wrong.
James
--
On Tue, Apr 24, 2012 at 10:06 AM, James Turner wrote:
> It's probably a reference counting issue. FGAirport is a FGPositioned and
> hence reference counted. The Nasal Ghost is supposed to deal with this -
> when we create a ghost around the airport, we take a reference
> (SGReferenced::get) and w
On 24 Apr 2012, at 15:57, Curtis Olson wrote:
> I tried running with valgrind and the error didn't happen -- hmmm...
>
> Trying it again, but a valgrind startup is excruciatingly slow ...
It's probably a reference counting issue. FGAirport is a FGPositioned and hence
reference counted. The Nas
Hi James,
Here is a bit more information.
I added some printf's before the call to findClosest(pos, maxRange,
&filter) in f_airportinfo()
The first time through, this seems to work, it returns a valid pointer,
which gets passed to hashForAirport(c, apt) a few lines later.
In hashForAirport() I
See if this makes sense??
(gdb) frame 1
#1 0x0088fb79 in
hashForAirport (c=0x19e62860, apt=0x6a128d0) at
/home/scotth/Download/Flightgear/git-repo/flightgear/src/Scripting/NasalPositioned.cxx:113
113
std::string name = apt->name();
(gdb) print apt
$1 = (const FGAirport
*) 0x6a128d0
(g
On 24 Apr 2012, at 14:39, Curtis Olson wrote:
> For what it's worth, I'm seeing nearly the same thing ... similar back
> trace-- crashing in hashforairport() about 10-15 seconds after the splash
> screen has been removed and the sim presented for use.
Okay, that's good news since it rules out
On Tue, Apr 24, 2012 at 7:39 AM, James Turner wrote:
>
> On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
>
> > It doesn't depend - I got a crash at TNCM as well, also using both c172p
> and the ufo. So this must be something more generic.
> >
> >> Just to check, you have updated simgear as well? T
On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
> It doesn't depend - I got a crash at TNCM as well, also using both c172p and
> the ufo. So this must be something more generic.
>
>> Just to check, you have updated simgear as well? There's a bugfix in
>> there I applied at the same time.
>
>
> Okay, this is my fault, but I don't know why / how it's crashing for
> you. Presumably you have some aircraft or nasal that makes additional
> airportinfo() calls, and you've managed to find a test-case that my
> testing has not encountered. Unfortunately we need to find out the
> relevan
On 24 Apr 2012, at 11:41, Renk Thorsten wrote:
> Here's the output:
>
> (gdb) bt
> #0 0x5e3d9a08 in ?? ()
> #1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
>at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
> #2 0x088ddc29 in f_airportinfo (c=0x13bedd28, m
Oops, missed that part of the instructions *blush*
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
On 24 Apr 2012, at 11:31, Renk Thorsten wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x5e3d9a08 in ?? ()
> Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386
> glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386
> libXdmcp.i386 l
>>> Can you get a backtrace?
Okay, following your instructions I did make clean in any of my build folders,
ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and
flightgear, and did
gdb ./fgfs
run --log-level=info --airport=KSFO --disable-real-weather-fetch
--disable-fullscree
> I had similar problem this weekend, and a full rebuild (simgear +
> flightgear) solved the issue. I have the sentiment that changes
> to SGReferenced (in simgear) could have created this instability
I pulled everything fresh and compiled both simgear and flightgear new, so
things shouldn't be o
On 24 Apr 2012, at 09:20, Renk Thorsten wrote:
>> Can you get a backtrace?
>
> I can try if you tell me what I need to do...
(re-)Build fgfs with debug symbols:
-DCMAKE_BUILD_TYPE=Debug
when running cmake, might need to make clean + make again
then run fgfs
gdb fgfs
run --log-level=
Hi Thorsten,
> > Can you get a backtrace?
>
> I can try if you tell me what I need to do...
>
> > I've made a change to the startup sequence,
> > yesterday, but I would expect it to crash later (after scenery
> > loading),
> > ten seconds sounds too early.
>
> Misunderstanding: After scenery l
> Can you get a backtrace?
I can try if you tell me what I need to do...
> I've made a change to the startup sequence,
> yesterday, but I would expect it to crash later (after scenery loading),
> ten seconds sounds too early.
Misunderstanding: After scenery loading and I find myself in the
On 24 Apr 2012, at 09:04, Renk Thorsten wrote:
> I've just pulled and compiled simgear and flightgear and pulled a fresh
> FGData to start package the next lightfield shader version, but it turns out
> the resulting binary is unstable.
>
> I get segfaults about 10 seconds after startup with th
On Sunday 19 February 2012 15:28:05 Scott wrote:
> On Sun, 2012-02-19 at 14:40 -0700, dave perry wrote:
> > On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> > > Am 19.02.2012 21:54, schrieb dave perry:
> > >> Hi All,
> > >>
> > >> I have been gone for almost a year. I want to start new source trees
On Sun, 2012-02-19 at 14:40 -0700, dave perry wrote:
> On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> > Am 19.02.2012 21:54, schrieb dave perry:
> >> Hi All,
> >>
> >> I have been gone for almost a year. I want to start new source trees
> >> for simgear and flightgear and track on going developme
On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> Am 19.02.2012 21:54, schrieb dave perry:
>> Hi All,
>>
>> I have been gone for almost a year. I want to start new source trees
>> for simgear and flightgear and track on going development. Which git
>> branches should I "check out" in this new set o
Am 19.02.2012 21:54, schrieb dave perry:
> Hi All,
>
> I have been gone for almost a year. I want to start new source trees
> for simgear and flightgear and track on going development. Which git
> branches should I "check out" in this new set of directories? And from
> the e-mails I have read fr
Hi James,
thanks for bringing this up (again)! Last Sunday I actualy started documenting
the use of rebase when
applying mere-requests: http://wiki.flightgear.org/Git#Merge_requests Would be
nice if you (and others,
like our Git-pro AndersG) could extend/correct it ;)
In the "new" git rules w
On 14 Dec 2011, at 09:32, Anders Gidenstam wrote:
> If your topic is freshly rebased it will just be a fast-forward merge,
> that is, your new commits are just added to the history of master.
> Nice and linear IMHO.. :)
Yes, sorry, I didn't express that clearly at all - thanks Anders!
James
On Wed, 14 Dec 2011, James Turner wrote:
> Of course, when you do finally merge your topic into next, that's a
> merge - because we do all care about recording that action in the
> history.
If your topic is freshly rebased it will just be a fast-forward merge,
that is, your new commits are jus
As far as my (still limited) understanding goes, gitorious needs to know the
public SSH key of the machine you're uploading from. Just login at gitorious,
go to dashboard, and click Manage SSH keys.
HTH,
Durk
On 03 Nov 2011, at 09:03, Michael Sgier wrote:
> Ok I did a fgdata clone:
>
> https
Michael Sgier wrote:
> Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata
Why did you go through all the hassle of creating an isolated workspace
instead of cloning the repo directly at Gitorious ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who it
Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata
and pulled that ~3.5GB. Now I've added the aircrafts but push gives:
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
fatal: protocol error: expected sha/ref, got '
---
> Michael wrote:> If I do a git merge, as above, it seems to put into a wrong
> directory? Any changes needed?
> And how/who to ask for Flightgear inclusion?
You cannot simply merge a subdirectory. You should clone fgdata, add your
aircraft to your
clone and then request a merge from that one.
Ok so now I've added it as:
http://www.flightgear.org/forums/viewtopic.php?f=4&t=11040&start=60
If I do a git merge, as above, it seems to put into a wrong directory? Any
changes needed?
And how/who to ask for Flightgear inclusion?
Thanks
Michael
-
>> Yes, true, we noticed that already. Hence we'll have to leave it as it
>> is right now. A bit unfortunate, this would have really shrunk the
>> archive significantly. But we may still be able to do that one day...
>
> The two biggest chunks in Models/ are Weather/ (110 MByte) and
> Geometry/ (35
>> Um... not true. Cloud textures and models currently reside in
>> /Models/Weather/ and as far as I know are modified within fgdata, but are
>> not in the scenery database.
>
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have
ThorstenB,
ThorstenB wrote:
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
The two biggest chunks in Models/ are Weather/ (110
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
It's a finite task to move the Weather/ folder elsewhere (i.e. out of
Models/) and d
On 17.10.2011 09:11, thorsten.i.r...@jyu.fi wrote:
>> The "Models" folder for example, since that's not maintained there -
>> it's just a copy of what is maintained in the scenery database
>> and we shouldn't modify it directly in fgdata.
>
> Um... not true. Cloud textures and models currently res
> The "Models" folder for example, since that's not maintained there -
> it's just a copy of what is maintained in the scenery database
> and we shouldn't modify it directly in fgdata.
Um... not true. Cloud textures and models currently reside in
/Models/Weather/ and as far as I know are modified
Am 16.10.2011 20:01, schrieb Alan Teeder:
> Flightgear already has such a system for scenery. You only download
> what you want, or need. Very few users need scenery for the whole
> world.
> Extending this concept to the bloated aircraft section of fgdata
> seems quite logical.
It's important tho
Newsgroups: list.flightgear-devel
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] GIT
Cedric Sodhi wrote:
> Developers have buoyantly indulged in their lethargy as ever before and
> passionately ignored the topic wherever it came up.
I don't know everybody&#
o the basis idea that we don't need all of
the aircraft in GIT for testing is correct.
Hal
>
> > Date: Sat, 15 Oct 2011 23:33:14 +0200
> > From: flightg...@sablonier.ch
> > To: flightgear-devel@lists.sourceforge.net
> > Subject: Re: [Flightgear-devel] GIT
> &g
Christopher Baines wrote:
> Though the current state will be annoying for new developers on average
> speed internet connections as afaik, git cannot clone, stop half way,
> then continue.
Someone's providing a starter-package containing just the bare
repository for download via HTTP. I don't r
, and when checking aircraft specific
issues it's a quick job updating only the one plane under exam.
Cheers,
Alessandro
> Date: Sat, 15 Oct 2011 23:33:14 +0200
> From: flightg...@sablonier.ch
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] GIT
>
Am 15.10.11 22:41, schrieb Christopher Baines:
> I know of another project who's main git repository contains a script,
> that manages the other git repositories, this allows them to split the
> gigs of data they have in to more sensible chunks, without having to
> pull every repository individuall
I know of another project who's main git repository contains a script,
that manages the other git repositories, this allows them to split the
gigs of data they have in to more sensible chunks, without having to
pull every repository individually.
Though the current state will be annoying for new
Cedric Sodhi wrote:
> Developers have buoyantly indulged in their lethargy as ever before and
> passionately ignored the topic wherever it came up.
I don't know everybody's favourites but, anyhow, maybe it's also a
matter of preferences. Personally I'd hate having to pull dozends of
repositories
Hi Michael,
On 30 Sep 2011, at 12:33, Michael Sgier wrote:
> Durk, I only saw now the lszh ai. How should I create such for other airports?
>
>
>
The LSZH network was done by a very early version of taxidraw and misses a lot
of features that were subsequently added. I still need to find som
Durk, I only saw now the lszh ai. How should I create such for other airports?
Martin, I've no problem releasing all on GPL but I won't go asking all
authors for permission nor be responsibly for any violations.Anyone having all
permissions, feel free to integrate my Suisse04 airports in fgfs.
--
Michael Sgier wrote:
> Martin ur a jerk.
I know :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
From: Martin Spott
Subject: Re: [Flightgear-devel] git
To: flightgear-devel@lists.sourceforge.net
Date: Friday, September 30, 2011, 10:05 AM
Durk Talsma wrote:
> If you have committed apt.dat files, to robin peel [...]
That's quite interesting. As far as I understood from Michael's
Durk Talsma wrote:
> If you have committed apt.dat files, to robin peel [...]
That's quite interesting. As far as I understood from Michael's various
rants, he doesn't license his work under the GPL - please correct me if
I'm wrong. On the other hand, you automagically license under the GPL
by t
Hi Michael,
On 29 Sep 2011, at 08:44, Michael Sgier wrote:
>
> Durk: I've only seen some lone hangars with terrasync but no probably not all
> as they are for 850 format. As HB-GRAL stated some airports are way off in
> old 810 format, so using a custom start or tower view location from my
>
On Thu, 29 Sep 2011, Anders Gidenstam wrote:
> For example:
>
> git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata
Oups, that should be
git remote add my-fgdata g...@gitorious.org:~andersg/fg/anders-fgdata.git
Cheers,
Anders
--
--
On Thu, 29 Sep 2011, Frederic Bouvier wrote:
> If you cloned the official data repository on your own machine, you
> won't be allowed to push anything.
>
> What you have to do is to clone the repository in your own
> gitorious.org project and then clone that clone on your own machine. As
> it i
- Mail original -
> Thorsten: I had an account and created a ssh key. Now it has a red
> cross
> below ready in gitorious. Something wrong with that?
> Now the fgdata clone should be on my pc alike the fgfs wiki or where?
> How to push or put a merge request??
If you cloned the official
Thorsten: I had an account and created a ssh key. Now it has a red cross below
ready in gitorious. Something wrong with that?
Now the fgdata clone should be on my pc alike the fgfs wiki or where? How to
push or put a merge request??
Durk: I've only seen some lone hangars with terrasync but no pro
> create mode 100644 Scenery/Airports/L/S/G/LSGS.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/G/LSGS.twr.xml
> create mode 100644 Scenery/Airports/L/S/M/LSMP.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/M/LSMP.twr.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZB.groundnet
On 28.09.2011 14:57, Michael Sgier wrote:
> Am I doing something wrong or do I need permissions etc.?
Did you create an account on gitorious.org and add your SSH key? Next
step then is to create a personal fgdata clone with your gitorious
account. The idea is to push your personal changes to you
is Olson wrote:
From: Curtis Olson
Subject: Re: [Flightgear-devel] git
To: "FlightGear developers discussions"
Date: Tuesday, September 27, 2011, 5:25 PM
On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:
HiI've messed up weather in fgdata. How could i discard local changes a
Subject: Re: [Flightgear-devel] git
On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:
HiI've messed up weather in fgdata. How could i discard local changes and only
get changes/original files? Git says to be up to date but weather is broken.
Later I'll do my fi
On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:
> Hi
>
> I've messed up weather in fgdata. How could i discard local changes and
> only get changes/original files? Git says to be up to date but weather is
> broken.
>
> Later I'll do my first upload. (groundnetworks.xml etc.) I do alike the
>
Sorry that I've dropped the ball on this. I will take a look at that
code soon and try to get it into the source tree.
Tim
On Tue, May 17, 2011 at 9:58 PM, wrote:
>> Hi Jack,
>>
>> I'm kind of slogging through a stressful day today with some other stuff
>> hanging over my head. If the patches
> Ron beat me to it, but I was going to suggest the same thing ... create
> an alouette2-easy-set.xml ... or aloutte2-beginner-set.xml or something
> along those lines. Then we can have both FDM's available and the end
> user can choose which one they want. A git commit war would be no fun.
I'
Ron beat me to it, but I was going to suggest the same thing ... create an
alouette2-easy-set.xml ... or aloutte2-beginner-set.xml or something along
those lines. Then we can have both FDM's available and the end user can
choose which one they want. A git commit war would be no fun.
On Wed, May
On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote:
> I would like to have the old fdm back, maybe it is possible to have another
> version with the easy-to-fly-fdm beside the original one.
>
> Any opinions about, something I missed?
>
> Heiko
Helijah's workflow should make it dead simple to cr
Hello all,
> Does anyone know, if JM-26, the author of the new fdm, is
> reading the
> devel list or has an email address for me to contact him
> directly?
>
> Regards
> Maik
>
I found the author on another french FlightGear Forum.
Here you go:
http://equipe-flightgear.forumactif.com/t504-l-a
Hi,
Am 18.05.2011 21:09 schrieb Heiko Schulz:
>
>> If the drawbacks introduced by the new
>> FDM are really that
>> obvious and serious as you've stated here, I'd say you/we
>> should take a
>> revert of the latter change into account.
> At least the author of the first and in my eyes much more rea
>
> In general I'd recommend first to discuss the item with the
> author of
> the change.
In general it is my prefered way as well. With any author just but not this one
for some reasons.
> If the drawbacks introduced by the new
> FDM are really that
> obvious and serious as you've stated he
Heiko Schulz wrote:
> I hate to say it, but the the new fdm is completly wrong and doesn't
> apply to the real one in any way.
In general I'd recommend first to discuss the item with the author of
the change. If the drawbacks introduced by the new FDM are really that
obvious and serious as you'v
> Hi Jack,
>
> I'm kind of slogging through a stressful day today with some other stuff
> hanging over my head. If the patches are intended to go into the main
> line,
> I'd love to have Tim take a pass at reviewing them. For a quick hack you
> could just do a traditional "diff -c" sort of patch
Hi Jack,
I'm kind of slogging through a stressful day today with some other stuff
hanging over my head. If the patches are intended to go into the main line,
I'd love to have Tim take a pass at reviewing them. For a quick hack you
could just do a traditional "diff -c" sort of patch if you wanted
Hello Luuk,
First I have to say Thanks for answering!
> When you use git rebase, it tries to
> replay your local commits on top
> of the new commits in the master branch. If you have
> multiple commits
> to the same files locally that have also been committed
> upstream, you
> will be trying to
When you use git rebase, it tries to replay your local commits on top
of the new commits in the master branch. If you have multiple commits
to the same files locally that have also been committed upstream, you
will be trying to replay old changes on top of new ones. A better
solution when you hav
Ok, I think I figured this out. The clue was in the error message I posted.
I had the branch in question checked out in my main repository clone, so
the system couldn't push changes from my --local clone of the branch back
into that branch in the primary clone.
I guess that makes some sort of se
No one has answered yet which makes me guess (a) I didn't ask very well or
(b) no one knows the answer, so let me try again here.
I created a local clone of my fgdata repository using the --local option
which builds hard links to the master original repository and saves lots of
space. The clone r
On Wed, Jan 26, 2011 at 1:21 AM, Stefan Seifert wrote:
> Well you don't. Often you just can leave modified files in place while
> switching
> branches. If it's not working, you still can simply git stash before
> switching. git stash creates a temporary branch and commits your local
> changes
> t
[saw this in time to de-lurk]
On 01/25/2011 11:22 AM, Anders Gidenstam wrote:
> I suspect the option --local to git clone might be useful.
> I have not tried myself, though.
Yeah, this is the best answer for this kind of problem.
The .git directory ends up being near-zero size (so long as the de
Curtis Olson wrote:
> The other implication here is that it would be extremely handy to have
> multiple branches checked out simultaneously for other reasons. git makes
> branching easy, yes, but if you find yourself bouncing between branches with
> changes for separate projects, and external eve
1 - 100 of 301 matches
Mail list logo
