RetroBSD

2.11BSD operating system for microcontrollers
It is currently Tue Jun 25, 2019 7:13 am

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Repository now on GitHub
PostPosted: Wed Apr 09, 2014 2:56 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
I have created a GitHub organisation and imported the current google code repository.

The URL for the repository is https://github.com/RetroBSD/retrobsd

Regular contributors are welcome to join the organisation - PM me (or email me if you know my address) with your github username and I'll see about adding you.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Thu Apr 10, 2014 3:28 am 
Contributor

Joined: Mon Apr 29, 2013 1:56 am
Posts: 196
Is this supposed to be a replacement for the SVN repo at code.google.com, is the SVN repo going to be retired?

I'm asking 'cause forks are cheap nowadays and people make them for a plethora of reasons (e.g. my Smaller C has been forked 4 times so far and only one forker has done some work in his fork and nobody has pulled a single change from my repo into their fork to keep things in sync; which makes me wonder, does forking on github equate with liking on facebook?:)).


Top
 Profile  
 
PostPosted: Thu Apr 10, 2014 9:22 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Yes, we are looking at replacing the google code SVN repo with Github. Chiefly because Github provides a much better user interaction experience - the pull requests, issue tracker, etc. It's much better for widly distributed collaborative programming than the likes of SVN, which is much more geared towards tighter-knit teams.

Plus I was fed up of Pito emailing me updated fils to include in the repo :P

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Fri Apr 11, 2014 9:34 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Here's a few tips and tricks for working with the github repo:

1. Fork your own copy of the repo, make changes, push to your copy, then submit a pull request. We will review the changes, make sure they work for us, and merge the request.

2. Keep your repo up to date with changes from the master:

This can be simply done by linking your repo to the master as an "upstream" repo:
Code:
$ git remote add upstream git@github.com:RetroBSD/retrobsd.git

You now have 2 places you can fetch from - origin (your repo) and upstream (master repo). To get the latest master code into your repo:
Code:
$ git fetch upstream

and to force a fetch from your repo (which should be the default anyway)
Code:
$ git fetch origin

3. If you're going to start doing something radically world shaking that has the potential to affect a lot of files / subsystems, create yourself a branch to do it in. It may take a bit of testing before it can be merged into the main repo, so we'd like to keep it separate until we're happy with it. To create a branch:
Code:
$ git checkout -b newBranchName

and to switch between existing branches:
Code:
$ git checkout branchName

To find which branch you are on:
Code:
$ git branch
  master
* newBranchName

(The one marked with a * is the current branch)
To merge a branch back into your master branch:
Code:
$ git checkout master
$ git merge branchName

Remember, it will only merge code that you have committed to your branch (though not necessarily pushed to your fork).

If you no longer want a branch:
Code:
$ git branch -d branchName

and it's gone!

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Fri Apr 11, 2014 10:53 am 
Contributor

Joined: Mon Apr 29, 2013 1:56 am
Posts: 196
majenko wrote:
2. Keep your repo up to date with changes from the master:

This can be simply done by linking your repo to the master as an "upstream" repo:
Code:
$ git remote add upstream git@github.com:RetroBSD/retrobsd.git

You now have 2 places you can fetch from - origin (your repo) and upstream (master repo). To get the latest master code into your repo:
Code:
$ git fetch upstream

and to force a fetch from your repo (which should be the default anyway)
Code:
$ git fetch origin



That part is misleading. Here's what works for syncing forks to their ancestors:
https://help.github.com/articles/syncing-a-fork
And after all those commands on the page, one more thing:
Code:
$ git push


Top
 Profile  
 
PostPosted: Mon Apr 14, 2014 5:41 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
I've installed git-gui into my ubuntu 10.10.
Nice. Everything there. Just push a button.. :)

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Sat Apr 26, 2014 9:24 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Can I urge people to be more wordy with their git commits? I for one have been really bad in the past with short one-liners for most commits.

I'd like to push for a "standard" format for all git commit messages:

Firstly, don't use the '-m "message"' format of committing - leave that bit out of your commits. Instead, make use of the editor facility.

Secondly, can you make your commit messages into two sections. The first section, just a single line and no more than ~ 50 characters, should be a brief summary of the change. Then please leave a blank line and then write a few lines describing the change, and more importantly, the reason behind the change. Try and wrap the lines around 70-ish characters if you can.

Till now it's not really been an issue, but once we reach our first release milestone I would like to start using git's log facility to build a changes list for each new release. The more information we can get into the commit messages the easier it will be to do the releases properly.

As an example, here's a commit message from UECIDE:
Code:
    Create and populate FileType class
   
    The new FileType class describes just what can be done with any of a number
    of file types.  It is intended to describe to the IDE how different files
    can be handled in the IDE - whether they can be edited (and how), what
    syntax highlighting to apply to them, etc.  At the moment it only handles
    basic information, but eventually it may be expanded to deal with deciding
    how a certain file type should be compiled (which recipe to use for it)
    etc.  This should make expanding the system to cover other languages in the
    future much simpler.

Then a simple change list can be generated from a given release - this is what the next version of UECIDE will be having (amongst other things I'm sure) as an example of how the changes log is generated (this is all changes since the last release 0.8.5b - you can also get changes between two releases by putting a later release code after the ...):
Code:
$ git log --format="%h %B" 0.8.5b...
80e3a47 Made better use of the build.number in build scripts

Traditionally the "Build Number" of a package has been the total number
of commits to the git repository since the beginning of time.  That number
is destined to grow rather large, and become a bit meaningless.  This small
change instead uses the number of commits since the most recent tag - that
is, the most recent release version.  That way it's basically the patch
level of the current version.  You can easilly see how many changes there
have been in your copy of the code since the last official release.  In
theory this will always be 0 for publicly released versions, but sometimes
a small post-release-tag tweak will be needed, so may be 1 or 2.  The
number is of more use to developers who share their builds with other
people so that the exact revision number can be determined with ease.

b44452a Create and populate FileType class

The new FileType class describes just what can be done with any of a number
of file types.  It is intended to describe to the IDE how different files
can be handled in the IDE - whether they can be edited (and how), what
syntax highlighting to apply to them, etc.  At the moment it only handles
basic information, but eventually it may be expanded to deal with deciding
how a certain file type should be compiled (which recipe to use for it)
etc.  This should make expanding the system to cover other languages in the
future much simpler.

01de1e4 Obtain version number from git tag

Nw we have transitioned to using git tags for marking release points it makes
sense to use those tags themselves for filling in the version number in the
IDE when compiling.  Both the master build and the core build scripts use
the output of "git tag" as the version number instead of getting it from
the version.txt file.

dbfd941 Automatically set UECIDE environment variable if unset

External third party scripts and makefiles can now access the UECIDE
environment variable to get the location of the "settings" directory.
This is the directory which contains preferences.txt and also usually
the compilers, boards, etc.  For instance, you could now use something
like:

$ $UECIDE/compilers/pic32-tools/bin/pic32-gcc ....

within a script.

This commit also standardizes the license boilerplate in all .java files
in the main UECIDE core source.


I know I have been one of the biggest culprits of bad commit messages, but let's all try and get into the habit of writing more.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission