Hah! Tony caught me! Yes, I made a small boo-boo yesterday and had to switch the order of two commits. ;)
In addition to the in-depth answer above, I'd just like to add I typically `make clean` whenever I pull a new revision down. 80% of the time it's not necessary, but especially if you haven't updated in a while, it can nip compilation problems in the bud to just do that first and wait the extra minute or two as it rebuilds the core julia c code. -E On Fri, Aug 15, 2014 at 5:53 PM, Tony Kelman <[email protected]> wrote: > You're fine, you're just seeing some consequences of the confusing way git > submodules work. For some dependencies that are managed within JuliaLang on > github, they are set up as submodules in the deps folder so it's easier to > work on them while still in version control inside a Julia source tree. > > The next time you do make after a submodule changes, Julia's makefiles > should update the submodules for you. Or you can manually update them with > "git submodule update", should work the same way. > > git fetch just checks github and updates the remote information about > what's available, doesn't make any changes to your local working copy. Git > pull does a fetch and then merges the latest changes into your working > copy, assuming you don't have any conflicting changes locally. If you > haven't touched anything, usually this is just a "fast-forward" that brings > your copy up to date with what's on github. Unfortunately the submodules > don't auto-update, which is what looks confusing here. > > I personally do a make clean every time I pull, just because Julia's C > codebase is pretty small and quick to rebuild. make clean doesn't touch the > dependencies. You can sometimes get away with not doing make clean, just > doing git pull && make instead, but since building the Julia system image > (the list of .jl files that goes by) is the most time-consuming part of a > build, I prefer avoiding any potential problems and just cleaning all of > the C each time. > > The release-0.3 branch is where the release tags will be made from, but > also future simple bugfixes that don't have to do with any of the breaking > changes currently being made on master will also be backported to > release-0.3. So to keep up to date with those bugfixes before the next > point release of 0.3.1, you should be use the release-0.3 branch, yes. Tags > are supposed to never change, unless Elliot does any more rebases and force > pushes hoping noone notices. > > > On Friday, August 15, 2014 2:37:03 PM UTC-7, Ross Boylan wrote: >> >> If I pull new source from julia can I just repeat the build procedure >> (without even, e.g. make clean)? Does it matter if it's within 0.3 or >> 0.3 to 0.4? (I plan to take the advice to stay off 0.4, but am >> wondering about the general principles.) >> >> I take it from previous discussion that I don't need to do anything to >> my packages as long as I stay within a point release, like 0.3. >> >> I also have some questions about how to get the new source; they are >> mostly git-related, but perhaps someone here could help me out. >> >> My original clone was ~ a month ago when master was tracking 0.3. I >> just did a git pull and then >> $ git checkout release-0.3 >> M deps/libuv >> M deps/openlibm >> M deps/openspecfun >> M doc/juliadoc >> Branch release-0.3 set up to track remote branch release-0.3 from origin. >> Switched to a new branch 'release-0.3' >> $ git diff >> diff --git a/deps/libuv b/deps/libuv >> index a12eb33..4c58385 160000 >> --- a/deps/libuv >> +++ b/deps/libuv >> @@ -1 +1 @@ >> -Subproject commit a12eb3329cd2c0224ef631ea062fa16d119da47c >> +Subproject commit 4c58385dd22eb36c1eccbe1460ef67e7fe182ae0 >> diff --git a/deps/openlibm b/deps/openlibm >> index 0b9d67e..da6c9c1 160000 >> --- a/deps/openlibm >> +++ b/deps/openlibm >> @@ -1 +1 @@ >> -Subproject commit 0b9d67e54a5b07e32a27b68cf0a01c33b515fc9b >> +Subproject commit da6c9c1805f773f83ece3eca64323f87ffdda845 >> diff --git a/deps/openspecfun b/deps/openspecfun >> index f3036c0..1b9edfb 160000 >> --- a/deps/openspecfun >> +++ b/deps/openspecfun >> @@ -1 +1 @@ >> -Subproject commit f3036c094ae56fdf447092a871ea4fe27fdeec16 >> +Subproject commit 1b9edfbd8c7a4d4cd13159d1001664a811ee02dd >> diff --git a/doc/juliadoc b/doc/juliadoc >> index bab3c6b..fe3db72 160000 >> --- a/doc/juliadoc >> +++ b/doc/juliadoc >> @@ -1 +1 @@ >> -Subproject commit bab3c6ba9e613da94001e1d71f994143814a1422 >> +Subproject commit fe3db7224daf4798ac950f7aa2c6ae7b60b85491 >> >> I am not sure what is going on or what I should do. >> >> Why did the checkout produce modified files instead of just switching? >> >> Why the strange and minimalist differences? Do I need to do some kind >> of git command to update the subprojects? >> >> In retrospect I probably should have done a git fetch rather than a >> pull. Not sure if that's related to any of my problems. >> >> Finally, is release-0.3 the right branch to be on to have the latest 0.3 >> code? Should I use a tag instead? >> >> Thanks. >> Ross Boylan >> >>
