Talk:git migration

• I'm sorry. Is this a roadmap (as in: has the fpc team decided to move to git), or is this just a proposal from someone who prefers git over svn? --Bart (talk) 22:48, 16 December 2017 (CET)

• We (the current fpc core team) is looking into the migration and collect all information about it on this page. It depends on the information on this page, if we do the migration or not --FPK (talk) 17:07, 17 December 2017 (CET)

Thanks for the answer. --Bart (talk) 22:00, 17 December 2017 (CET)

• Regarding the following point under Cactus Workflow... no time consuming micro management of branches. I disagree with that as a positive point for cactus workflow. In fact, that workflow suggests you micro-manage commits by cherry-picking commits one by one into other branches. Commits are bound to be overlooked or missed. Git was designed to handle branches and merges with least amount of effort (I can quote Linus Torvalds if you need facts and examples). Merging one or more branches are a single command. Multiple branches merged at the same time is called a octopus merge, but works the same as a single branch merge. Git resolves merges as much as it can (and does a brilliant job - better than SVN) and only raises issues for lines of code it can't figure out how to merge itself. Also you can ask git (a single command) to show which branches haven't been merged yet. You can also ask git to list commits that haven't been merged from a long running branch or from multiple branches - again a single command. Git does branching very well and very simply. I work in my day job with 50 developers using SubVersion. They are all scared of branching - simply because SubVersion does it so badly. Git is NOT like that. There is nothing scary about branches in Git, and any local action can be undone without effort or a commit history of what you attempted. --Graeme (talk) 19:12, 17 December 2017 (CET)

Why are they scared of branches in svn? It is very simple: svn cp trunk branches/mybranch. The scary part is merging. Not the merging itself, but the conflict resolution because several people changed the same LOC. And this does not change with git significantly (if at all). --FPK (talk) 23:17, 17 December 2017 (CET)

There are so many interfaces to SubVersion and each one works differently or have different features sets (that don't exist in the svn CLI version). Our company uses TortoiseSVN, but even that has multiple ways of creating branches (with or without commit history), and merging commits fail very often even though branches are only a couple days old. We can't merge many commits in one go, we have to do them 1 or 2 commits at a time to prevent the merge failures. This all seems to scare the developers here from using branches. I've merged long and short term branches under Git, and Git does a massively better job at merging and reducing conflicts than SubVersion. Anyway, coming back to my original statementt - micro-managing commits, one-by-one is a pita and not a benefit. --Graeme (talk) 14:32, 18 December 2017 (CET)

Well, we need to "micro-manage" either commits or branches. The "commits" approach has the advantage that is done by the fixes maintainer which has the needed exprience and normal contributors have not to bother. I doubt that less frequent contributors get a complicated workflows right. --FPK (talk) 20:20, 19 December 2017 (CET)

Fixes maintenance proposal

• Create another clone of main repository (:= fixes-clone)
• When new fix is accepted into mainline, create new branch (cherry pick commit if it fix is just one commit in upstream), rebase it on fixes branch root (last shared commit with master) and push to fixes-clone.
  • If you try to add same fix twice new branch HEAD will have same hash.
• Fix can added to fixes branch by cherry pick or merge, it does not matter.
• Delete merged branch

--AlexVinS (talk) 11:30, 20 December 2017 (CET)

Sounds reasonable, otoh it might double work: in the worst case it means that a fix needs two times conflict resolution. At least it sounds like opening a nut with two screwdrivers by fixing them with pliers because one does not own a proper wrench. --FPK (talk) 19:37, 20 December 2017 (CET)

Version 2

• Create another clone of main repository (:= fixes-clone)
• When new fix is accepted into mainline, create new branch (cherry pick commit if it fix is just one commit in upstream), leave it forked from same commit in master, push to fixes-clone.
• Fix can added to fixes branch by cherry pick or merge, it does not matter.
• Rename merged branch <x> to merged/<x>
• Cleanup on fixes branch end of life.

Copyright file history

Regarding FPK's comments on old copyright code that was cleaned many FPC version ago. Is it really needed to try and delete those old files and blowing away any history of those files in the process? The past is the past, and I believe preserving the history of any file is a good thing. The last couple of releases all have the clean implementations. The history of these files (good or bad) shows that the Free Pascal team went through the trouble of removing copyright code - that's considered a good thing. --Graeme (talk) 10:38, 4 January 2018 (CET)

It was confirmed in the cease-and-desist response that we would stop distributing the source by any means. That still stands. Also mirroring copyrighted content on external sites (like github) is dodgy. Marcov (talk) 13:09, 19 February 2018 (CET)