Difference between revisions of "Talk:git migration"

From Free Pascal wiki
Line 2: Line 2:
  
 
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 --[[User:FPK|FPK]] ([[User talk:FPK|talk]]) 17:07, 17 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 --[[User:FPK|FPK]] ([[User talk:FPK|talk]]) 17:07, 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. --[[User:Ggeldenhuys|Graeme]] ([[User talk:Ggeldenhuys|talk]]) 19:12, 17 December 2017 (CET)

Revision as of 20:12, 17 December 2017

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)

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)