Here is a preview of what will be the final GitHub repository hosting Slicer sources: https://github.com/jcfr/Slicer-Git
Update: Preview repository has been removed. Sources are now available at https://github.com/Slicer/Slicer
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 https://github.com/jcfr/Slicer-github-transition-scripts
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: http://svn.slicer.org/Slicer4/trunk@28773” 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:
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.
Maybe we could fix links to the SVN repository (e.g., the commit comment contains “git-svn-id: http://svn.slicer.org/Slicer4/trunk@28773” 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.
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)
Has there been any progress on this transition?
Working on this today. Stay tuned
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 https://github.com/Slicer/SlicerGitSVNArchive 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.
Waiting all stub issues are created do
NOT follow the Slicer repository on GitHub, it will spam your inbox.
Cc: @cpinter @lassoan @pieper
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 ?
- Updated repository is now available at https://github.com/Slicer/Slicer
- We now have 112 identified GitHub contributors
- Issue tracker links used in commit message have all been consolidated to use
- Pull request links used in commit message have been updated to reference
- Contributors are properly acknowledged by leveraging the
Co-authored-by: git trailer
- Link to svn repository has been added using
svn-url: git trailer.
- More details available at https://github.com/jcfr/Slicer-github-transition-scripts#readme
- Original repository has been renamed to SlicerGitSVNArchive
- A new FAQ has been created.
- Issue tracker:
- All issues from Mantis have a corresponding issue in GitHub
- Creation of Mantis issue has been disabled
- Moving forward, we will be using GitHub issue tracker
- SVN server:
Thank you so much @jcfr for working on the migration! This was very important and delicate, so also thanks for doing it with such care
This is awesome!
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:
- 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)
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.
Create Developers group and add people who we want to be able to assign issues to.