The Unicon Project Blog

A modern descendant of the Icon programming language.

Brought to you by: btiffin, jafaral, jeffery, slumos

Unicon's svn to git Guide - Part 1

Unicon's svn to git Guide

This is a simple guide written to help Unicon users and developers who are not familiar with git. The goal is to ease the transition from svn to git. svn is a great revision control system, but git is more flexible when it comes to managing multiple branches and repository mirrors allowing more feature experimenting and code sharing.

Git is a distributed revision control system. Once you get a copy of the code (through cloning) all of the commits, checkouts, and branches are local to the repo on your machine. When you do an initial git clone from a remote server you get everything from the server, a complete copy of the code and the revision history. The repo at the server side is no better than the repo you just cloned.

From a revision control perspective, there is no such thing as a server. There is no git server in the same sense as an svn server. There are git remotes; other git clones of the same repo you have that you can get code from or share and push code to. The first time you clone a git repo it remembers where you cloned it from (the url) and it is given the default label "origin", i.e where you originally cloned the repo from. If you are a developer you will rarely work on one remote, because you want to get code from different clones of the repo or you want to push code to multiple repos.

If you are strictly a user of the Unicon language and do not make any changes after you download the sources from the git repo then the situation is very similar to svn days; get a copy of the code and build from sources just like before.

Cloning

Clone the git repo to your local machine:

git clone git://git.code.sf.net/p/unicon/unicon

This will result in having a full clone of Unicon's git repo on your local machine in a directory named unicon placed under the current path:

JMBPro:demo jafar$ git clone git://git.code.sf.net/p/unicon/unicon
Cloning into 'unicon'...
remote: Enumerating objects: 40851, done.
remote: Counting objects: 100% (40851/40851), done.
remote: Compressing objects: 100% (10948/10948), done.
remote: Total 40851 (delta 29652), reused 40819 (delta 29634)
Receiving objects: 100% (40851/40851), 29.93 MiB | 12.13 MiB/s, done.
Resolving deltas: 100% (29652/29652), done.
JMBPro:demo jafar$

By default one branch is checked out called "master" which is the default git branch name for the "main" development branch. cd to the unicon directory you just cloned and issue the command:

JMBPro:unicon jafar$ git branch -v
* master c1d333c9 Fix copy() to handle arrays

"master" is the current branch, "c1d333c9" is the name/hash of the last commit, the rest is the commit title/comment.

Changing the argument to the command to -vv displays also the remote branch tracking information, while "-a" lists also branches available on the remote repo since you last "synced" with the remote repo:

JMBPro:unicon jafar$ git branch -vva
* master                c1d333c9 [origin/master] Fix copy() to handle arrays
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master c1d333c9 Fix copy() to handle arrays

Building

For most users, just move on to build as usual:

./configure

make

Optionally you can install or add unicon/bin to your path

make install

Updating

To update yourcurrent branch on the local repo from the remote repo do:

git pull

If you are on the master branch, all updates to the remote master branch will be pulled in. For example:

JMBPro:unicon jafar$ git pull
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git://git.code.sf.net/p/unicon/unicon
   c1d333c9..05639e57  master     -> origin/master
Updating c1d333c9..05639e57
Fast-forward
 README    | 48 ------------------------------------------------
 README.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+), 48 deletions(-)
 delete mode 100644 README
 create mode 100644 README.md
JMBPro:unicon jafar$

Developers

[Update September 2020]
[ Development switch to github repository ]. The development setup descibed here is the same excpet the fork/clone is heppening off Github instead of Sourgeforge]

If you plan to do development on Unicon and possibly share your code with others or submit patches it is best to create your own fork of Unicon on SourceForge. To do that, browse to Unicon's git repo on Sourceforge:

https://sourceforge.net/p/unicon/unicon

Click "Fork" from the options on the left pane and you will be taken to the next page to select where to place the fork and what to call it assuming you have an account on SourceForge and you are logged in. Leave the default options and click the "Fork" button. The result is effectively a clone of Unicon hosted publicly under your account on SourceForge. You can then clone Unicon from your own repo and push changes to it since you have write-access. You can think of this public repo as a sandbox where you can use such a repo to keep experimental changes or features you are working on. It also serves as a place where you can share code with others and get feedback or help in preparation to submit the changes to the Unicon Project. More importantly, when your code is ready you can do a "Request Merge" from the left pane directly available on SourceForge from your own fork. "Request Merge", also known as a "Pull Request", is a way to inform the project (Unicon in this case) maintainers that you have code ready to be merged in the main project. The maintainers can then give feedback or ask to make changes. Once all issues are addressed, a maintainer can merge the code with a click of a button.

A typical setup would be to create a fork on SourceForge then do a clone from the fork. After that the main Unicon repo can be added as a second remote repo. For example after cloning my own fork I have:

JMBPro:unicon jafar$ git clone ssh://jafaral@git.code.sf.net/u/jafaral/unicon

I can check which remote(s) I have by issuing the command:

JMBPro:unicon jafar$ git remote -v
origin  ssh://jafaral@git.code.sf.net/u/jafaral/unicon (fetch)
origin  ssh://jafaral@git.code.sf.net/u/jafaral/unicon (push)

I have one remote labeled as origin which points to my own fork. I then add the main (by convention called upstream) Unicon repo as a remote to get the latest update:

JMBPro:unicon jafar$ git remote add upstream git://git.code.sf.net/p/unicon/unicon

Let us check what remotes I have now:

JMBPro:unicon jafar$ git remote -v
origin  ssh://jafaral@git.code.sf.net/u/jafaral/unicon (fetch)
origin  ssh://jafaral@git.code.sf.net/u/jafaral/unicon (push)
upstream    git://git.code.sf.net/p/unicon/unicon (fetch)
upstream    git://git.code.sf.net/p/unicon/unicon (push)

Again, origin is the default label given to the repo cloned first. upstream is the label I chose to refer to the main Unicon repo. Let us check what branches I have and what remote branches I know about.

JMBPro:unicon jafar$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/readme

I only know about the branches in the origin repo. I need to do a fetch before I know what the upstream repo has to offer.

JMBPro:unicon jafar$ git fetch --all
Fetching origin
Fetching upstream
remote: Enumerating objects: 34, done.
remote: Counting objects: 100% (34/34), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 24 (delta 15), reused 0 (delta 0)
Unpacking objects: 100% (24/24), done.
From git://git.code.sf.net/p/unicon/unicon
 * [new branch]        master     -> upstream/master

I could also do git fetch upstream if I want to only fetch updates from the upstream repo. Let us check the remote branches again:

JMBPro:unicon jafar$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/readme
  remotes/upstream/master

This looks better! Now I'm ready to make changes. I will create and checkout a new branch to implement a new feature. It is always good to make sure your are up to date with the upstream repo. Let us check where all branches stand:

JMBPro:unicon jafar$ git branch -vva
* master                  762e2cd8 [origin/master] fix segfault if invoked with no args
  remotes/origin/HEAD     -> origin/master
  remotes/origin/master   762e2cd8 fix segfault if invoked with no args
  remotes/origin/readme   7603459e Update README
  remotes/upstream/master 05639e57 Update README and ename it to README.md for better online rendering

My current branch is master, and it is up to date with remote master on my own fork. However, there are updates on upstream master that I need to bring in to my local master branch. To do that I issue:

JMBPro:unicon jafar$ git merge upstream/master
Updating 762e2cd8..05639e57
Fast-forward
 .gitignore            | 789 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 README                |  48 ---------
 README.md             |  62 +++++++++++
 bin/.gitkeep          |   0
 ipl/cfuncs/bitcount.c |   4 +-
 plugins/lib/.gitkeep  |   0
 src/h/version.h       |   2 +-
 src/runtime/fmisc.r   |  16 ++-
 8 files changed, 869 insertions(+), 52 deletions(-)
 create mode 100644 .gitignore
 delete mode 100644 README
 create mode 100644 README.md
 create mode 100644 bin/.gitkeep
 create mode 100644 plugins/lib/.gitkeep

Another check on where all branches stand:

JMBPro:unicon jafar$ git branch -vva
* master                  05639e57 [origin/master: ahead 5] Update README and ename it to README.md for better online rendering
  remotes/origin/HEAD     -> origin/master
  remotes/origin/master   762e2cd8 fix segfault if invoked with no args
  remotes/origin/readme   7603459e Update README
  remotes/upstream/master 05639e57 Update README and ename it to README.md for better online rendering

My local master branch is now in sync with the upstream master branch. I do see on the first line of the output [origin/master: ahead 5]; that is because the local branch that was originally checked out of the master branch from the "origin" repo is updated and is ahead by 5 commits compared to it. We don't have to worry about that for now. We can just create a new branch and start working on a new feature. To create a new branch called foo you can use "git branch foo" and then check the branch out by "git checkout foo". To do both commands at once you can do:

git checkout -b foo
Switched to a new branch 'foo'

List the branches we have now in the local repo:

JMBPro:unicon jafar$ git branch 
* foo
  master

Posted by 2019-09-02