Forum

git repository for Hiawatha

Stephen R. van den Berg
4 July 2013, 08:28
First of all: Hugo, many thanks for starting to use git to manage/publish the sources.

In your current repository I noticed the following things:
- A .gitignore file is absent, which would have protected you against inadvertent checkins as the build/* and *.o files.
- You did not use any tags to mark revisions.
- It appears to be contaminated with a large build/* checkin and subsequent removal, this blows up the repository unnecessarily.
- There appear to be some random *.o files being checked in at times.
- The history stops at 8.5.

You are welcome to clone and/or copy my version of the Hiawatha repository which includes:
- History back to 2005 version 3.7.
- A .gitignore file in the BuGless branch which I highly recommend to avoid inadvertent checkins.
- Tags for all revisions so it is easy to look back.
- Numerous other suggested fixes in the BuGless branch.
- Clean checkins of all revisions (without build/* or *.o files).
- Better commit descriptions (taken from your Changelog file).

To use it, perform:

git clone git://git.cuci.nl/hiawatha

The master branch is your cleaned up history for all revisions from 3.7 leading up to 9.2.
The BuGless branch is built on top of the master branch, and contains all fixes I use in my local branch.

Hiawatha version: 9.2
Operating System:
Stephen R. van den Berg
4 July 2013, 08:58
For the git novices:

To view the master branch on my repository after cloning use: git log origin/master
To view the BuGless branch on my repository after cloning use: git log origin/BuGless

Please note that when you clone my repository, the branch that ends up being your local master (git log master) will most likely be a copy of the origin/BuGless branch, since that is the branch that I have actively checked out here most of the time.
Hugo Leisink
4 July 2013, 10:50
Thanks for the info. I've added a .gitignore file, which will be uploaded with the next release. I've also added tags to the existing releases. I don't think it's necessary to go al the way back to 3.7. Nobody should be using such old releases.
Stephen R. van den Berg
4 July 2013, 20:52
Well, besides the obvious cleanups and getting this for free, I'd say the benefit of having a history that goes back further lies in the fact that it is easier to figure out which bug was fixed in what release, and if there are any regressions, it's more clear-cut to see where they came from.
Stephen R. van den Berg
5 July 2013, 12:44
To ease transitioning I now updated and encompassed your tree in mine.
There now are three branches:

hugo This is your current git repository, verbatim.
master This is the cleaned up version of your repository with longer history and improved commit messages.
BuGless This is the same as master, but then with my own fixes/patchset on top of that, this branch tracks master, and therefore cannot be tracked by itself (it's rebased everytime master receives an update).

I currently manually import updates from hugo to master, and then rebase BuGless to fit.

Incidentally, just today I fixed some annoying race conditions in the main server and in the PolarSSL code (in the BuGless branch).
Hugo Leisink
5 July 2013, 18:29
Can your place them in Github? Than it's easier to see the differences.
Stephen R. van den Berg
5 July 2013, 22:29
Github is less flexible than selfhosting for me.
Maybe you mean something like this:

http://devel.cuci.nl:8080/gitweb.cgi?p=hiawatha.git;a=summary

If that is not what you were looking for, please explain what github allows you to see more, I can undoubtedly support the same view github is providing.
Stephen R. van den Berg
5 July 2013, 23:07
Well, played around a bit with github. If it helps, take a look at this:

https://github.com/BuGlessRB/BuGless

It's got all three branches.
Stephen R. van den Berg
5 July 2013, 23:45
Ok, I now understand that github somewhat limits the flexibility of git. So, in order to make things easier, I forked your repository on github, and then added the "clean" and "BuGless" branches, in addition to that I created a "bugfix" branch which fits right onto your current master branch, and which can be merged with that directly (for all the patches you would like to incorporate).
Stephen R. van den Berg
5 July 2013, 23:48
I just now sent you a pull request from my fork to your master branch.
Stephen R. van den Berg
8 July 2013, 13:15
Ok, rearranged the patches. I now "carpetbombed" your github tree with four merge requests, separating the patches in maintenance, bugfixesonly, performance and securitylockdown groups to ease integration and approval using the mere github interface.

I added a performance patch to lower the load and increase the throughput using proper TCP options.
Hugo Leisink
8 July 2013, 19:37
GitHub is not my main repository, it's on my server. I only use it because of its nice interface to browse code and for more publicity. I'll take a look at your changes and apply them to my local code if I accept them. Thanks for your feedback.
Stephen R. van den Berg
9 July 2013, 10:41
I see. Excellent.

In that case, you can skip the whole github mumbo-jumbo and fetch from git://devel.cuci.nl/hiawatha directly, which is my working repository.
Stephen R. van den Berg
10 July 2013, 14:00
Just updated the performance patch, forgot to exclude SSL connections in the TCP_CORK case.
This topic has been closed.