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:
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
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
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
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
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.
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
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
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
15 matches
Mail list logo