The first step in migration to Git is pretty much complete. You can
find the new repositories at https://github.com/gnustep/.
## What happened?
Gna.org has shut down, and we have luckily had an rsynced copy of the
entire Subversion history backed up. I've spent most evenings last
week writing a tool to execute the conversion in a safe,
conversion- and history-respecting fashion. Then I've uploaded the new
repositories into Github. My local count says that I've processed our
history into 64 repositories.
Care has been taken to have authors' names preserved and displayed in
the Git fashion: that is, names and email addresses have been set.
If you see an issue with the used emails or names, please notify me
as soon as possible while we can still rewrite history with minimum
impact on everyone's work! I don't expect I'll want to do this after
As we have previously had a Git mirror, a large part of history has
been previously available to other users. To make the transition less
painful, Git replace refs have been generated. To fetch them, and thus
have many Git base commands 'pretend' that the old hashes are the same
as the newly exported hashes, please do as follows:
git fetch origin 'refs/replace/*:refs/replace/*'
After this, if you do a 'git log master' and 'git log old', you can
note that both commits have the identical 'new-style' authorship, and
they have the same parent. This is an illusion, of course, done by
using the replace refs in .git/refs/replace directory.
If you would prefer this information as JSON, it's been uploaded
into the gitsvn-scripts repository.
### Are you sure the conversion was done correctly?
While I do not expect significant problems with the converted repos,
certainly there must have been some loss of history. Not only is all
software buggy (and I've certainly had some odd crashes on behalf of
git-svn during the process), but I've also only covered repositories
that exist today (not those that may have existed in the past). Git
also has a different idea about whether empty directories do or do not
This is why a backup of the Subversion history has been made available
for enterprising software archaeologists.
## How to contribute?
Prospecting contributors can, at this time, create Github pull
requests to contribute. The process is as usual: create a fork, push
into the fork, create a pull request on Github web UI.
If you decide you wish not to interact with Github beyond performing a
git clone, rest assured: your "git format-patch" output can be
accepted on gnustep-dev@. (Please reach out before mailing them out,
however, as everyone is still getting settled into the new
environment. Please keep the patchsets smaller, as we are used to low
volume of traffic on gnustep-dev@.)
Long-standing contributors can reach out to me or Gregory with their
Github usernames and get direct write access. Note that you do not
/need/ this to contribute; you can create pull requests, or otherwise
arrange that someone pulls from your fork.
IMPORTANT: All contributors are still expected to have filed the
copyright assignment paperwork with FSF. While small patches can be
accepted, substantial patches will be held until we are assured that
the copyright assignment has been filed.
IMPORTANT: Don't forget! Set up your real name and email correctly
before creating commits:
git config --global user.email "firstname.lastname@example.org"
git config --global user.name "Some name"
### Can I edit history, and push -f?
Even if you have write permissions that would allow you to push -f, I
would *strongly recommend* that you refrain from doing so. *Any* edits
to pushed history that's been pulled already will cause pain for other
Always coordinate any edits to the history. If edits are observed,
they may be reverted without a warning.
Refrain from editing far into the past without a strong reason and
even more coordination.
### Should I delete branches or tags?
Deletion of branches and tags in Git can and will *delete history*,
and confuse other contributors. Even if you have write permissions
that would allow you to do this, do *not* delete branches or tags
## Can I be notified of commits?
Please subscribe to email@example.com. While the emails
do not contain patch content, they're still useful as notifications of
These notifications will be moved elsewhere, possibly reusing
firstname.lastname@example.org. Hopefully whatever hosting platform we move to
will allow us to mail out pushed patches as well.
## Is this a move to Github?
Strong and vocal feedback of the community has been heard and Github
is intended as a temporary stop. We'll sort out a different hosting
provider, most probably self-hosting the repositories, some time in
When the time comes, you will be either asked to sign up for this new
service, or be given a pre-created account. It's expected that you
will need to supply the SSH public keys again, just like with Github.
## Can you help me with Git or Github?
I will be happy to help long-standing contributors.
Otherwise, please use online documentation to learn how to contribute.
If you continue having questions after having played with Git for a
while, please start a new thread on discuss-gnustep@.
## Can I use Github features such as issues/wiki/pull requests/projects?
I would discourage use of anything that we cannot trivially migrate
off of. Issue tracking is one of those things.
Therefore, issues have been disabled on almost all of the
repositories. Please notify Gregory or myself if you would like to
make use of the Issues feature, but do note that, while possible, it
will not be trivial to move off of Issues in future.
If you do not need Issues, please continue using Savannah to file and
manage bugs for the time being.
Wiki uses markdown. We have historically not held documentation in
markdown, nor has our main wiki been based around markdown.
For this reason, wiki has been disabled on all the repositories.
If you require wiki, please notify Gregory or myself and we will
enable the feature for you.
### Pull requests
Please make use of them for the time being. They are a useful feature
to accept contributions.
We are not using the development methodology embodied in the Projects
feature. It would not be possible for us to migrate off of it. Please
do not use it.
For this reason, projects have been disabled on all the repositories.
If you require Projects, please notify Gregory or myself and we will
enable the feature for you.
## Can I use Subversion?
Github currently happens to offer Subversion access. Review their
documentation for instructions. Revision numbers have, obviously,
changed. Please don't rely on this being consistent and
long-term-available; while we will probably continue mirroring to
Github no matter where the main home is, I would not rely on this
being a super-reliable offering with stable revision numbers etc.
There are otherwise no plans to continue offering access to GNUstep
source tree through Subversion.
### I mean, can I obtain the backup of the Subversion repos that you used?
For the time being, the backup is available over:
This should be the file as delivered to me by Gregory Casamento over
Google Drive. I do not have reason to suspect this file's integrity.
I'm therefore GPG signing the sha256 signature of the file as
currently stored on my local hard drive. Please verify the sha256sum
after downloading this file; I have not spent time on setting up HTTPS
on that machine.
-----BEGIN PGP SIGNED MESSAGE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
I expect to upload this to archive.org or similar for posterity.
## Will other GNUstep-related projects (GAP, gnustep-nonfsf, gnustep
website, ...) be migrated to Git?
I will be happy to assist in transition if requested. If I have time,
I will even poke the relevant parties to plan and coordinate a
However, no transition is explicitly planned at this time.
## Closing note
While this has been quite a bit of effort, I hope the output is useful
and that Git will both bring us into the present, and helps us with
speed at which we make changes.
Discuss-gnustep mailing list