Thanks Mr. Peterson for taking the time to share how us less technical folks use git :)
Still foggy :) When my evening quiets down I'll give it a spin and see what this yields. Looks like (in part) what needs amended to the docs. Still prominently telling one to use SVN for latest source (even in git web interface main screen). Bunch of stuff like that outstanding. Glad to help cleanup the documentation and amend this type of info if technically knowledgeable folks share the details. On 1/23/12, M. David Peterson <[email protected]> wrote: > On Mon, Jan 23, 2012 at 3:55 PM, pub crawler > <[email protected]>wrote: > >> Can you share the recommended way to get latest complete source from Git? >> > > Depending on your definition of "latest" (latest unreleased development, > latest tagged release, latest commit to the master branch) you'll first > need to clone the /cherokee/webserver repository with the --recursive > option and then switch (if necessary) to the desired dev branch. So: > > git clone git://github.com/cherokee/webserver.git --recursive > > ... will clone the webserver repo and the repo's of all submodules. Your > local copy will have the master branch checked out and whichever sha1 > commit of the related submodules was last specified for that branch. The > master branch is a few commits ahead of the v1.2.101 tag, but as far as I > know the commits don't represent changes to the working code, though I'll > need to verify. Either way, to checkout the latest official release > (v1.2.101): > > git checkout -b [local_branch_name] v1.2.101 > > ... will checkout the latest tagged release using whatever name you chose > as the name of the local branch (which can be the same as the tag name if > you want). If you don't necessarily need a local branch to work from (hack > on code, commit locally, push to remote repo) you can simply run: > > git checkout v1.2.101 > > ... which will leave your local repository in a detached HEAD state which > is fine if you have no plans to make changes to the code base that needs to > tracked as part of a specific branch. If you do make changes that need to > be tracked as part of a branch you can run: > > git checkout -b [local_branch_name] > > ... when in the detached head state. Any commits you've already made and > all future commits made while you have this branch checked out will be > tracked by that branch which you can then merge into another branch when > ready and/or push to a remote repo. > > Alvaro will need to comment on which of the development (SPDY, dev, or > new-events) branches represents his current workflow, but my assumption is > that the dev branch is where all of the other branches have or will get > merged into. So to switch to the bleeding edge: > > git checkout -b [local_branch_name] dev > > With all of the above you'll want need to run: > > git submodule update > > ... to ensure all submodules match the sha1 committed to the index for the > related branch. > > We need to update the docs with clear how-to on this. Can't find >> such in the documentation. >> > > Agreed. I'll add it to my task list, though can you specify whether the > above adequately answers your question? > > -- > /M:D > > M. David Peterson > Co-Founder & Chief Architect, 3rd&Urban, LLC > Email: [email protected] > Voice: (801) 742-1064 > http://amp.fm | http://mdavidpeterson.com > _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
