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
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 anders-...@gidenstam.org wrote:
On Mon, 14 Oct 2013, grtuxhangar team wrote:
Hello,
with FG 2.99 Data i am getting
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
skip the
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,
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 to
On Thu, Aug 9, 2012 at 10:44 AM, Anders Gidenstam
anders-...@gidenstam.orgwrote:
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
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
On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson curtol...@gmail.com 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
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), which
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 Wed, Aug 8, 2012 at 10:45 AM, Curtis Olson curtol...@gmail.com 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
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 curtol...@gmail.com wrote:
A quick
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
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
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
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 the
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 loading and I
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
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 out
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-fullscreen
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
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: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, me=
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
relevant
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.
I did
On Tue, Apr 24, 2012 at 7:39 AM, James Turner zakal...@mac.com 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
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
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
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
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 Nasal
On Tue, Apr 24, 2012 at 10:06 AM, James Turner zakal...@mac.com 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
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:35 AM, James Turner zakal...@mac.com 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
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 :
SGSharedPtrMyClass myPtr = new MyClass;
then
delete myPtr;
or
delete myPtr.get();
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 removed
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 the
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 curtol...@gmail.com wrote:
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
As far as the FGPositioned Octree is concerned (which is what
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
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 that
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 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
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 from the
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 of
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 development. Which git
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
for simgear
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 just
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
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 we
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 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
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:
Ok so now I've added it as:
http://www.flightgear.org/forums/viewtopic.php?f=4t=11040start=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
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.
See
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
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 reside in
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
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 really
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 MByte).
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's favourites
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
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
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 individually.
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
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
Am 15.10.11 22:41, schrieb Christopher Baines:
I know of another project who's main git repository contains
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 some
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
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
...@mgras.net wrote:
From: Martin Spott martin.sp...@mgras.net
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
Michael Sgier wrote:
Martin ur a jerk.
I know :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
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.
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
- 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 data
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 is
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
--
.?
Cheers Michael
--- On Tue, 9/27/11, Curtis Olson curtol...@gmail.com wrote:
From: Curtis Olson curtol...@gmail.com
Subject: Re: [Flightgear-devel] git
To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net
Date: Tuesday, September 27, 2011, 5:25 PM
On Tue, Sep 27, 2011 at 4
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
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.xml
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
wiki
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 first upload
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, cas...@mminternet.com wrote:
Hi Jack,
I'm kind of slogging through a stressful day today with some other stuff
hanging over my head.
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'm
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've
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 here,
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 realistic fdm
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:
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 create
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
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
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
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 replay
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
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
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
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 events
[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
On Wed, Jan 26, 2011 at 1:21 AM, Stefan Seifert n...@detonation.org 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
On 24.01.2011 22:49, James Turner wrote:
Perhaps another approach would be to do out-of-source builds. I think
automake/conf should support that, although it's been a while since I've
tried it.
Cmake is very good at out-of-source builds :)
Hmm. The out-of-source builds alone don't really
On Tue, 25 Jan 2011, ThorstenB wrote:
You'll also need to keep git from touching any _sources_, so maintain
two sets of matching sources and their objects. Using two completely
separate repos helps - or the magic feature to create two separate
source checkouts from one repository, which James
On 25 Jan 2011, at 19:22, Anders Gidenstam wrote:
I suspect the option --local to git clone might be useful.
I have not tried myself, though.
The thing I was thinking of is:
git-new-workdir
Which essentially symlinks the key pieces of .git between two different dirs.
Documentation
On Tue, Jan 25, 2011 at 1:22 PM, Anders Gidenstam wrote:
I suspect the option --local to git clone might be useful.
I have not tried myself, though.
Once you get it all figured out, please let us know how, so we can get setup
correctly too. :-)
Thanks,
Curt.
--
Curtis Olson:
1 - 100 of 277 matches
Mail list logo
