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)
• Clean-up branches
  • Make all (release) branches protected branches to prevent accidental force-pushes and other potentially destructive actions (equivalent to bzr append-only branches)
    • If no further commits are supposed to happen to them, they could be marked as 'protected' via gitlab interface (which allows you to set very fine-grained merge and push permissions).
  • 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. (done by Eduard)
    • 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 whether 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
    • inkscape.dev_credentials should probably be moved to a separate repository
• 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: [tghs]
  • Windows: CI via Appveyor and MSYS2 prepared [Eduard], needs authorization by GitLab user with "owner" permissions.
• 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 will always be rebased on top of the master branch before merging making the merge commit "Merge branch some_feature ..." unnecessary) (enabled by Bryce)
  • 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)
• Organization
  • Perhaps send out invitations to devs who have not registered yet? This can be done from the 'members' tab of the 'Settings' page by project masters and owners.
  • Double-check permissions. Decide on whether Inkscape devs should be given developer status for all Inkscape subgroups, or only on their own subgroup.

Questions/Confusions

• How does one get a liat of branches?
• How can one have a set of parallel branches: trunk, 0.92.x, 0.91.x ...?
• Should it be 'origin/0.92.x' rather than '0.92.x'?

Get full commit history

(probably needs to be placed somewhere else eventually, Eduard (talk) 03:11, 12 June 2017 (UTC))

I just found out, that our git import has the full history back to 2003-10-30 (it's in 0.45.x/0.46.x branches) while trunk only reaches back to 2006-01-16 (we're missing 8691 revisions in total).

 179fa413b047bede6e32109e2ce82437c5fb8d34  -->  first commit in trunk/master
 971d8ce896dc59d3ec6430610d6ae28586c1301f  -->  the same commit in 0.45.x/0.46.x (but has no relationship with trunk/master)
 9ed8de136577ccaaae3289dd4165171573c7bcbc  -->  initial commit in 0.45.x/0.46.x

Nice thing about git: We can stitch together both histories using git-replace!

A simple

 git replace 179fa413b047bede6e32109e2ce82437c5fb8d34 971d8ce896dc59d3ec6430610d6ae28586c1301f

will tell git that it should replace the first commit in trunk/master with the same commit in 0.45.x/0.46.x.

As a result all revisions descending from 179fa413b047bede6e32109e2ce82437c5fb8d34 will now have proper ancestry reaching back to 9ed8de136577ccaaae3289dd4165171573c7bcbc.