Timeline for Commit code transformations in git
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 14, 2018 at 1:53 | answer | added | Greg Burghardt | timeline score: 2 | |
| Jul 13, 2018 at 15:58 | comment | added | Max Murphy | @candied_orange Don't get yourself into a position that requires pulling stunts. | |
| Jul 13, 2018 at 15:34 | comment | added | Max Murphy | This is going off topic but hey. APIs should be stable. Code behind an API should be mobile. I am very much in favour of not just refactoring but also having multiple implementations of an API. Refactoring should change APIs as little as possible. Refactoring that crosses API boundaries breaks a contract with all the users of that API. A special space is preserved in hell for people who do that too much. It is this widely scoped refactoring that is bad. IDEs should make people think long and hard before changing public class methods, signatures, schemas etc. | |
| Jul 13, 2018 at 14:28 | comment | added | candied_orange | Refactoring should be cheap. If your use of source control is keeping it from being cheap that doesn't mean you should stop refactoring. It means you should rethink the way you're using source control. Same with unit tests, integration tests and peer reviews. Refactoring is WHY we use code instead of soldering irons. Clamp down on refactoring and your code is dead. Code is like concrete. Stir it often or it will set and become hard. | |
| Jul 13, 2018 at 13:10 | comment | added | Max Murphy | That depends on the individual programmer and on how confident that they are that a given branch can be rebased without conflict. More radical changes => greater likelihood of breaking changes. However that is kinda beside the point. If the rebase goes smoothly but renames a property, a normal rebase is not going to find all the new uses of that property and fix them. Ditto with libraries being moved, signatures changing and so on. One push can interrupt the workflow of the entire team. Multiple people actively following the same "refactor is cheap" mentality and you have havoc. | |
| Jul 13, 2018 at 12:45 | comment | added | DaveG | How frequently do you do merges? If the code is fairly up to date between the branches renaming should go pretty smoothly. | |
| Jul 13, 2018 at 11:56 | answer | added | Karl Bielefeldt | timeline score: 3 | |
| Jul 13, 2018 at 11:54 | comment | added | Blrfl | I'd refer you to the second page of Per Cederqvist's Version Management with CVS: "CVS is not a substitute for management. ... CVS is not a substitute for developer communication." Your developers clearly don't understand the ramifications of their actions. Get some discipline into their lives. | |
| Jul 13, 2018 at 11:51 | comment | added | Max Murphy | It doesn't support scala out of the box but there seems to be a windows plugin that might be adapted: github.com/sageserpent-open/SemanticMergeScalaPlugin | |
| Jul 13, 2018 at 11:38 | history | asked | Max Murphy | CC BY-SA 4.0 |