Transition to GitHub

Here is a preview of what will be the final GitHub repository hosting Slicer sources:
Update: Preview repository has been removed. Sources are now available at

Next steps:

Waiting we officially transition, please consider reviewing the history and reporting here if authorship or committer is incorrect.

For future reference, scripts and instructions are archived at


This will help us in so many ways, thank you for working on this!

Are you going to add stubs for issues in the bugtracker? (just the subject line, a link to the issue tracker, maybe first N lines of the issue description)

A few tweaks (none of them very important):
-Maybe we could fix links to the SVN repository (e.g., the commit comment contains “git-svn-id:” but this URL is not valid)

  • Maybe add a url to the corresponding commit in the old repository (so that we can easily find a commit based on the old hash)

That will be great!

not complelty related this, but I was wandering if it would be possible to fix the co-authorship for the following commits:

  1. markups

  2. 3d views linking

Andras can confirm my co-authorship for the two commits which I think it was lost in the review/merge process. If it is not possible to add the co-authorship anymore, no problem.

1 Like


Maybe we could fix links to the SVN repository (e.g., the commit comment contains “git-svn-id:” but this URL is not valid)

Good point. Instead I was thinking to add an other line of the form:


Of course, I will do.

Note that I will resume work on the transitioning to GitHub when back from traveling after March 1st.

1 Like

Sounds good. Thanks for all your hard work on this.

Any progress on moving to git. It is a bit annoying that contributions to svn to not retain attributions very well.

I really hope that @jcfr completes this within days and not weeks.

We save original author in commit comments and use it to look up author when converting the repository to git.

Thanks @lassoan I appreciate your support.

Sometimes attribution is the only compensation contributors get!


Yess, I re-ran all scripts yesterday and will plan on wrapping up next week. (Note: I am out of the office today and Monday)

1 Like

Has there been any progress on this transition?

Working on this today. Stay tuned :rocket:

Waiting this is complete, do not commit on either SVN or GitHub

cc: @lassoan @pieper @Sam_Horvath @fedorov @cpinter


The current repository has been renamed to and a new repository called Slicer has been created.

  • The new Slicer/Slicer is NOT yet ready for usage, the history will likely be updated tonight.
  • Preview build will be disabled tonight and re-enabled tomorrow.

Thanks for your patience


Can we get an update on this process?

Stub issues mapping with the mantis ones are being created.

1 Like

Waiting all stub issues are created do NOT follow the Slicer repository on GitHub, it will spam your inbox.

Cc: @cpinter @lassoan @pieper

1 Like

The new repo will be ready to accept contribution (Pull requests, new issue, comments, …) tomorrow

Nightly build will be re-enabled tonight.

Thanks for your patience

In the mean time, what should you do ?


Next steps:


Thank you so much @jcfr for working on the migration! :pray: This was very important and delicate, so also thanks for doing it with such care :slight_smile:


This is awesome! :champagne:

Thank you @jcfr for performing this migration with so much attention to all details. Preserving all the various links, history, contributions, etc. will be very valuable.

Can we start submitting pull requests (and rebase&merge them)?

@jcfr Awesome! Waiting for the green light ot make PR’s.


Few more things to set up:

  1. We should make master branch protected
  • “Allow force pushes” and “Allow deletions” unchecked: This make things safer and simpler (at the cost of not being able to cover up potential missteps). It also allows us to use commit count as a monotonously increasing counter for easier revision tracking (instead of SVN revision). It is a minor inconvenience that merge count does not appear in github GUI, but we can determine it quite easily at project build time.
  • Require pull request reviews before merging: checked (we should try this at least and disable if we find it too annoying or it slows things down too much)
  • Require status checks to pass before merging: unchecked (for now, until we are confident that checks work very reliably)
  • Require signed commits: unchecked (I have never used this, but probably not necessary)
  • Require linear history: checked (non-linear history is just too complicated)
  • Include administrators: unchecked (there is a warning displayed anyway if you exercise this right, that should be enough)
  • Restrict who can push to matching branches: checked (have a CoreDevelopers or similar sub category who are allowed to merge changes)
  1. Disable “Create a merge commit” option (only allow “Squash and merge” and “Rebase and merge”). Merge commits make reviewing change history a very complicated task.

  2. Create Developers group and add people who we want to be able to assign issues to.

1 Like