One of the nice things about git is that as long as things have been committed sometime in the past, things tend to be pretty resilient to screwing up, unless you do Dangerous Things (TM). (These are things like force pushes, rebases, etc...)
To speak in specifics, merely running git checkout v0.3.2 will set the working tree (e.g. the files on disk *right now*) to be the same as those in the commit that was tagged "v0.3.2". You are not on a branch, so when you type git status it'll complain about that. The reason I bring this up is because it's important to be on a branch if you want to pull changes down from GitHub to your local repository. When you run git checkout -b version0.3.2, you create your own branch called "version0.3.2" that is pointing to the same commit as the working tree was at the time you created it, (e.g. it will be pointing at the "v0.3.2" tag) but all this really buys you is the ability to switch between your "version0.3.2" branch and the main "release-0.3" or "master" branches. Personally, I do similarly to Ivar, I have a "julia" folder, that tracks "master", and I have a "julia-0.3" folder that tracks "release-0.3". I don't make a huge distinction between v0.3.2 and the HEAD of the release-0.3 branch, as since it's all fixes and backports, there's very little danger in building v0.3.3-pre versus v0.3.2 proper. The bonus is that since my local release-0.3 branch is automatically setup to track origin/release-0.3, anytime I do a git pull I automatically get the latest release-0.3 changes incorporated into my local repository. If I were sitting on a "version0.3.2" branch, that wouldn't happen without some extra configuration. -E On Mon, Oct 27, 2014 at 8:29 AM, David van Leeuwen < david.vanleeu...@gmail.com> wrote: > Related to this: > > On Sunday, October 26, 2014 8:17:16 PM UTC+1, Stefan Karpinski wrote: >> >> If you do `git checkout release-0.3` then you will be on the >> `release-0.3` branch instead of `master`; you can then proceed exactly as >> you used to but will only get the relatively conservative changes on that >> stable release branch. >> >> > what exactly is the canonical way to compile a specific release from git? > (I still find it hard to understand the general concepts of git and/or how > one should work with branches and tags). I came up with > > $ git checkout v0.3.2 > $ git checkout -b version0.3.2 > > the latter statement just not to loose the possibility to continue with > master, later. But I can't imagine this is the recommended way. > > Cheers, > > ---david > > >> On Sun, Oct 26, 2014 at 3:11 PM, harven <har...@free.fr> wrote: >> >>> Hi, I am currently using julia v0.3.1-pre+4 under a debian gnu/linux >>> system and would like to upgrade to the latest stable version 0.3.2. Should >>> I recompile from source or is there a faster way? >>> >>> I used to do `git pull origin` but I guess that would retrieve the 0.4 >>> version of julia. >>> Thanks for your advice. >>> >> >>
