Re: [Flightgear-devel] git work flow question
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 may require you to jump to a different branch at a moments notice, It's a major PITA to have to commit every little thing you are in the middle of to switch to another branch. This is like having to completely clean up your desk before you can work on a new task, and then clean it up again completely before you can jump to the next. I think you're looking after having multiple local clones of the same repository where you're checking out a different branch in each of them, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
[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 deltas between trees are small), and you pay only for the copy of the active tree. So resource consumption is more or less the same as having two checkouts of a remote tree. You do have to manage the extra steps required to push/pull/merge between the trees though. Andy -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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 local changes to that branch. git stash apply lets you get back those changes, even if you're on a different branch than before (it's just like a git merge stash). Hi Stefan, I created a new branch and then in that branch created some new files and committed them to that subbranch. I'm working on those new files. Any time I make a change to one of those files and then want to quickly switch to the master branch I get a lot of these... $ git checkout master error: You have local changes to 'Aircraft/foo/bar/newfile'; cannot switch branches (because this file doesn't exist in master and the branch switch requires deleting it.) Ok, I could see git stash helping, but wow, if I start getting a few branches going, that could potentially be a lot of extra typing and a lot of things to remember (or go and check) every time I switch branches. When I return to a branch do I have to remember to unstash some changes? If I forget (life gets complicated sometimes) am I going to waste time chasing issues I've already fixed? If I have several branches in play, and someone pushes an important change to fgdata/master (possibly tied to an important change in flightgear/next) that can almost lead to an hour of just getting my branches up to date (even with no direct conflicting files.) I agree that some changes that have not been committed can float back and forth through branch switching (just not the ones I'm making right now.) :-) I found the book Version control with git quite useful. Yes it's somehow strange to need a book for a simple tool like a VCS, but git's features are IMHO worth having to read a little. I've barely had a chance to crack open my applying RCS and SCCS O'Reilly book, and now I have to buy a new book? ... :-) I personally wouldn't call git a simple tool. Git takes a highly complex problem (version control) and splits it up into just about the smallest possible logical chunks. Then it leaves it up to the end user to remember which chunks to stitch together and in which order to achieve the highly complex task. Many common tasks are easy in git. But some things start to become a royal pain. Part of this is because I need to adapt my work flow to be more git compatible. But I think part of this is that git has some limitations and weaknesses too, and isn't completely perfect itself. -- switching gears -- Another thing I do a lot of is work on projects that put me out in the field or traveling. So I like to maintain my projects across multiple machines ... my office desktop pc, my laptop, possibly other machines too depending on the project. If I'm doing FlightGear based work, and I want to create a special branch for my little project, *and* I want to share that branch across multiple PC's and possibly do work at times from any of these PC's ... then I need to create that branch on a server some place. Do I want to pollute the official flightgear repository with a bunch of branches solely for the purpose of my little side adventures? Do I create a separate clone on a separate server and then try to keep those in sync? At some point I'm going to have to sit down and think through the whole process of the best way to share a private branch across multiple PC's ... and keep those all in sync with each other and the official master repository. It should be doable I think, but sounds to me like it will require typing a lot of commands in the right order to make it work right ... I'm sure there are many ways to make this all work cleanly, but the question I have is if there's a way to do it that isn't too kludgey/hackish, isn't too brittle and easily broken by upstream changes, and doesn't require an unreasonable amount of command steps to accomplish. Regards, Curt. -- 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/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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 help with switching branches. Changing branches back and forth still results in all differing sources getting new timestamps. So the next make triggers a rebuild of all affected sources/objects anyway. make isn't smart enough to notice that the older object files were generated from (older) sources, which had identical content to the current (newer) sources. So it's all the same if you maintained one or two sets of objects. 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 mentioned. Could some git guru (git-goroo? ;) ) enlighten me, on how I can create two checkouts from one repo? That would actually be very useful - especially now that fgdata is branched. I don't want to pull another fgdata repo... and I don't feel brave enough to switch fgdata branches, since its release branch is already stripped (= switching affects thousands of files...). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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 mentioned. Could some git guru (git-goroo? ;) ) enlighten me, on how I can create two checkouts from one repo? That would actually be very useful - especially now that fgdata is branched. I don't want to pull another fgdata repo... and I don't feel brave enough to switch fgdata branches, since its release branch is already stripped (= switching affects thousands of files...). I suspect the option --local to git clone might be useful. I have not tried myself, though. anders@sleipner:~$ git clone -h usage: git clone [options] [--] repo [dir] ... -l, --local to clone from a local repository ... anders@sleipner:~$ git clone --help ... OPTIONS --local, -l When the repository to clone from is on a local machine, this flag bypasses the normal git aware transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. This is now the default when the source repository is specified with /path/to/repo syntax, so it essentially is a no-op option. To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository), but still avoid the usual git aware transport mechanism, --no-hardlinks can be used. ... Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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 seems to be a bit lacking, though. James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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: 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/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, 25 Jan 2011, Curtis Olson wrote: Once you get it all figured out, please let us know how, so we can get setup correctly too. :-) I'm not sure this counts as figuring it all out.. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata 7930604 fgdata anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test Cloning into fgdata-test... done. anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/ 7930604 fgdata 4614988 fgdata-test/ After checking out the 2.2.0 branch in fgdata-test: anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test 7934896 fgdata 691112 fgdata-test A drawback is that the second clone fetches from the first so one would need to keep the first uptodate to get the latest commits in the second clone. It might be possible to set up fetch and branch tracking to avoid that. I'm not sure what happens if both clones fetch new commits from gitorious - probably that will lead to duplicate files (fetching from the first to the second local repro hopefully doesn't). Both repositories need to be on the same partition since filesystem hardlinks are used. The use of hardlinks also open up for some confusing du results - depending on in which order the files are attributed to directories. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git 3252104 fgdata/.git 4992fgdata-test/.git anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git 3246288 fgdata-test/.git 10808 fgdata/.git Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Tue, Jan 25, 2011 at 7:44 PM, ThorstenB bre...@gmail.com wrote: make isn't smart enough to notice that the older object files were generated from (older) sources, which had identical content to the current (newer) sources. Right. Enter ccache :) -- Csaba/Jester -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
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 may require you to jump to a different branch at a moments notice, It's a major PITA to have to commit every little thing you are in the middle of to switch to another branch. This is like having to completely clean up your desk before you can work on a new task, and then clean it up again completely before you can jump to the next. I just don't work like that, I bounce between about 12 desktops, 40 browser tabs, multiple coding projects. And then when someone pushes something to the remote repository, you have to clean up the desk again, switch to the master branch, do a pull, and then individually switch to each of your local branches and do a merge. Tedious to say the least, and intrusive to the continuity of my work flow! I know where everything is on my desk ... if you make me clean it up and put it all away 10 times a day ... yeah I have a spotless desk, but I can't actually get anything done! Hope that didn't sound too much like a vent, still trying to figure out how to merge the git view of the world with my own, and I'm still not entirely happy. :-) I'll definitely have to checkout the local checkout feature. Do we understand the branching/merging nuances in this case? Will I need to do a git pull in the master branch for each locally cloned repository or will the hard links ensure that a git pull in one repository is reflected in all the others ... no I suppose not, since the local clones are clones of the first repository ... we'll probably need to still do individual git pulls in each of them (from the master branch) to update them ... so still lots of branch switching and manual fiddling to maintain these local branches. Hmmm. Curt. On Tue, Jan 25, 2011 at 3:16 PM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Tue, 25 Jan 2011, Curtis Olson wrote: Once you get it all figured out, please let us know how, so we can get setup correctly too. :-) I'm not sure this counts as figuring it all out.. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata 7930604 fgdata anders@sleipner:/opt/FlightGear$ git clone -l fgdata fgdata-test Cloning into fgdata-test... done. anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test/ 7930604 fgdata 4614988 fgdata-test/ After checking out the 2.2.0 branch in fgdata-test: anders@sleipner:/opt/FlightGear$ du -sk fgdata fgdata-test 7934896 fgdata 691112 fgdata-test A drawback is that the second clone fetches from the first so one would need to keep the first uptodate to get the latest commits in the second clone. It might be possible to set up fetch and branch tracking to avoid that. I'm not sure what happens if both clones fetch new commits from gitorious - probably that will lead to duplicate files (fetching from the first to the second local repro hopefully doesn't). Both repositories need to be on the same partition since filesystem hardlinks are used. The use of hardlinks also open up for some confusing du results - depending on in which order the files are attributed to directories. :) anders@sleipner:/opt/FlightGear$ du -sk fgdata/.git fgdata-test/.git 3252104 fgdata/.git 4992fgdata-test/.git anders@sleipner:/opt/FlightGear$ du -sk fgdata-test/.git fgdata/.git 3246288 fgdata-test/.git 10808 fgdata/.git Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ 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/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] git work flow question
On Wednesday 26 January 2011 01:34:35 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 may require you to jump to a different branch at a moments notice, It's a major PITA to have to commit every little thing you are in the middle of to switch to another branch. 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 to that branch. git stash apply lets you get back those changes, even if you're on a different branch than before (it's just like a git merge stash). I found the book Version control with git quite useful. Yes it's somehow strange to need a book for a simple tool like a VCS, but git's features are IMHO worth having to read a little. Stefan -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] git work flow question
I have another git question: James has created v2.2.0 release branches on the git server. I would like to keep up-to-date builds of both versions here. If I switch branches in the source tree, git switches the files under version control but doesn't touch any files it doesn't know about. (Leaving all the build objects from the other tree.) With CVS/SVN, my approach was just to check out separate trees, one for each branch, have two completely independent builds, and then I could cvs udpate and then make in either tree to update my build of either branch. As far as I understand git, you can't have two separate/independent branches active for a repository at one time. If I do a build of the next branch, then switch to the releases/2.2.0 branch, I still inherit all the build object files from the other branch. So then I have to do a complete make clean; make for simgear and flightgear each time I want to jump from one branch to the other ... which could be quite often as the 2.2.0 release nears. This seems *highly* non-optimal in terms of wasted time and wasted work ... especially for people who might be bouncing back and forth several times in quick succession to test/edit/test/edit a bug fix in both branches. The other approach would be to have two completely separate git repositories, one that sits with the 2.2.0 branch checked out and one that sits with the next branch checked out, but that wastes a bunch of disk space and also seems really non-optimal. 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. What's the best way to handle this sort of work flow in the git world? Thanks, Curt. -- 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/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Mon, Jan 24, 2011 at 9:01 PM, Curtis Olson wrote: If I do a build of the next branch, then switch to the releases/2.2.0 branch, I still inherit all the build object files from the other branch. So then I have to do a complete make clean; make for simgear and flightgear each time I want to jump from one branch to the other I don't have a GIT answer to your question - but I'm surprised you need to make clean. Switching branches results in all changed/switched source files getting fresh timestamps - so the normal make dependency rules trigger a rebuild for the affected objects. And unless the branches diverge too much, it should be much quicker than a full rebuild. I'm curious though if there was a better GIT workflow (you're never finished with learning about GIT...). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
Hi Curt, The best way to handle this is definitely using out-of-source builds. In your git repo, just create build-branch dir's, and build from there. For autotools, just run ../configure make make install, or ccmake .. make make install if you want to use cmake. I do this all the time, works fine. Stefan 2011/1/24 Curtis Olson curtol...@gmail.com: I have another git question: James has created v2.2.0 release branches on the git server. I would like to keep up-to-date builds of both versions here. If I switch branches in the source tree, git switches the files under version control but doesn't touch any files it doesn't know about. (Leaving all the build objects from the other tree.) With CVS/SVN, my approach was just to check out separate trees, one for each branch, have two completely independent builds, and then I could cvs udpate and then make in either tree to update my build of either branch. As far as I understand git, you can't have two separate/independent branches active for a repository at one time. If I do a build of the next branch, then switch to the releases/2.2.0 branch, I still inherit all the build object files from the other branch. So then I have to do a complete make clean; make for simgear and flightgear each time I want to jump from one branch to the other ... which could be quite often as the 2.2.0 release nears. This seems *highly* non-optimal in terms of wasted time and wasted work ... especially for people who might be bouncing back and forth several times in quick succession to test/edit/test/edit a bug fix in both branches. The other approach would be to have two completely separate git repositories, one that sits with the 2.2.0 branch checked out and one that sits with the next branch checked out, but that wastes a bunch of disk space and also seems really non-optimal. 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. What's the best way to handle this sort of work flow in the git world? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On 24 Jan 2011, at 20:01, Curtis Olson 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 :) Of course configure can do them too - and as Thorsten noted, the normal dependency mechanism works okay when switching branches, unless it's a 'big' change. Finally, I believe there is a git feature to have multiple local 'checkouts' sharing the same .git repository. I.e saving disk space, and no need to push/pull to Gitorious to move things between them. I can't recall the correct name for this feature, though, but I asked a similar question to this one, and that was mentioned as a possible answer. James -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
