Talk:Working with Git

TODO list after the GitLab Migration

(feel free to modify and expand, Eduard (talk))

• Update build for git [Mc?]
  code compiles fine already but in some places we depended on bzr (notably for getting revno)
• Rename branches (we have ~100 branches imported and it's impossible to find anything). Suggestion:
  • Release branches (inkscape.dev_RELEASE_0_91_BRANCH, inkscape.board_0.92.x, etc.) are renamed to plain 0.91.x, 0.92.x, etc. This will automatically put them at the top of the branch list and should make searching for them easy. If no further commits are supposed to happen to them, they need to be marked as 'protected' via gitlab interface (which allows you to set very fine-grained merge and push permissions).
  • Other branches: Keep for now; see next bullet point
• Sort through other branches that are not release branches
  • Delete branches that are not needed anymore. (For example I realized branches of rejected merge requests were exported, too; I assume it's fine to get rid of them?)
  • In the long run: Decide wether to move those branches to another repo for safekeeping. I suggest we aim at only having release branches under inkscape/inkscape while feature branches of developers should reside in personal forks
• Re-add tags for past releases (some were lost during the migration)
• Set up continuous integration. There are already many devs excited to get CI up and running for different platforms! This will ensure to maintain a certain code quality down the line and prevent build breakages going unnoticed.
  • Linux:
  • macOS:
  • Windows: CI can be provided using Appveyor (they offer MSYS2) [Eduard]
• Decide on how we want to handle commit and repo access in the future.
  GitLab has much to offer to optimize what we did on Launchpad to make contributions easier while still making sure commits will not break badly. Some random thoughts that cam up already:
  • Should we enforce merge requests for all larger changes in future? These can be automatically checked via CI to prevent ever getting broken code into the master branch. If enough people are around we might even think about proper code review at some point.
  • Should we allow direct push access to the main repo or take the above a step further and require MRs for everything?
  • Who should be able to merge MRs? All developers or a group of select trusted devs? (review might create a bottleneck, so has to be carefully considered)
• Finalize set-up of GitLab repo
  • The previous bullet point will decide some settings regarding repo access
  • Shall we enforce "fast-forward merges"? (i.e. all merges wil always be rebased on top of the master branch before merging making the merge commit "Merge branch some_feature ..." unnecessary)
  • PRs are non-public right now (seems already fixed)
  • Consider moving inkscape-docs repo, board repo, windows devlibs repos etc. (and if done, remember to adapt website and wiki accordingly)