Timeline for Should the commit history be used to convey critical information to developers?
Current License: CC BY-SA 3.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 2, 2020 at 5:28 | answer | added | Vorac | timeline score: -1 | |
| Dec 30, 2014 at 10:31 | comment | added | Mark Booth | Fair enough, I was thinking more integration test than unit, and software isn't always easy, but I've been in this situation before and consider it a belt, braces and a piece of string situation: try to prevent with documentation (not that programmers ever read it), with comments in the code/dependencies (not that they are always visible if using an GUI or auto dependency tool) and detect with a test, just in case both are missed. | |
| Dec 29, 2014 at 15:14 | comment | added | rjzii | @MarkBooth I think that answer existed back when I accepted the accepted answer. I upvoted Karl's answer but wasn't a fan of having a unit test because it presupposes that a problem is easily unit testable. Plus, you would still need to have the problem documented somewhere else anyway since most people aren't going to read unit tests to find out that they shouldn't upgrade until after the test fails which wastes valuable time. | |
| Dec 28, 2014 at 20:02 | comment | added | Mark Booth | In the light of more recent answers, please reconsider your selection of accepted answer. Trying to document away this problem has significant risks. There is no better documentation than a passing or failing test. Although it is outvoted by over 8:1, Karl Bielefeldt's answer is is by far and away the best answer here. | |
| S Dec 21, 2014 at 2:02 | history | suggested | Andrew Marshall | CC BY-SA 3.0 | fix grammar |
| Dec 21, 2014 at 1:39 | review | Suggested edits | |||
| S Dec 21, 2014 at 2:02 | |||||
| Dec 19, 2014 at 21:38 | history | edited | MetaFight | CC BY-SA 3.0 | added 2 characters in body |
| S Dec 19, 2014 at 21:36 | history | suggested | samthebrand | CC BY-SA 3.0 | Great question that will be featured at Ars Techinca this weekend. I tried to make the first sentence a little less ambiguous, plus fixed a couple minor grammar choices. |
| Dec 19, 2014 at 21:10 | review | Suggested edits | |||
| S Dec 19, 2014 at 21:36 | |||||
| Aug 3, 2014 at 21:42 | vote | accept | rjzii | ||
| Aug 1, 2014 at 5:43 | history | protected | gnat | ||
| Jul 31, 2014 at 22:31 | answer | added | Pero P. | timeline score: 0 | |
| Jul 31, 2014 at 19:47 | answer | added | Karl Bielefeldt | timeline score: 17 | |
| Jul 31, 2014 at 18:26 | answer | added | wberry | timeline score: 2 | |
| Jul 31, 2014 at 9:08 | answer | added | JimS | timeline score: 0 | |
| Jul 30, 2014 at 22:14 | answer | added | Cort Ammon | timeline score: 2 | |
| Jul 30, 2014 at 15:55 | comment | added | Nathan | @Midnotion Yeah, that's entirely true. I think word of mouth sort of does the trick in the end, hopefully. However, the log in the commit history probably didn't help that process, it's more about discussion and emails etc. I don't think its an bad idea in addition to telling your colleagues btw, because people sometimes check these things when they're struggling with something. | |
| Jul 29, 2014 at 21:55 | history | tweeted | twitter.com/#!/StackProgrammer/status/494239894731231233 | ||
| Jul 29, 2014 at 20:38 | answer | added | Damon | timeline score: 14 | |
| Jul 29, 2014 at 19:21 | comment | added | Nick | Updating to the latest version of an SDK can be a pretty large change. This is probably something that should have been discussed as a group before being checked in. | |
| Jul 29, 2014 at 18:21 | comment | added | 17 of 26 | That still doesn't make it a good idea to put critical information solely in the commit history. | |
| Jul 29, 2014 at 16:54 | comment | added | Midnotion | On the path from new hire to lead dev, you need to take the time to understand the system and the reasons why it is that way. Let's face it, few real projects are thoroughly documented, and of those that are, there is so much to read that no new hire could be expected to understand it all. | |
| Jul 29, 2014 at 16:48 | comment | added | Nathan | @Midnotion So somewhere on the path from new hire to main developer you take time to go through the entire commit history? Fascinating. | |
| Jul 29, 2014 at 16:23 | comment | added | Midnotion | New hires should not be rolling through the code base and changing dependencies without specific direction to do so. | |
| Jul 29, 2014 at 15:58 | answer | added | Daenyth | timeline score: 71 | |
| Jul 29, 2014 at 15:53 | answer | added | stonemetal | timeline score: 13 | |
| Jul 29, 2014 at 15:49 | comment | added | Steven Evers | Do you require new hires to go through the entire commit history? | |
| Jul 29, 2014 at 14:32 | answer | added | Jeffery Thomas | timeline score: 34 | |
| Jul 29, 2014 at 14:23 | answer | added | 17 of 26 | timeline score: 143 | |
| Jul 29, 2014 at 14:18 | answer | added | JeffO | timeline score: 5 | |
| Jul 29, 2014 at 14:13 | answer | added | FrustratedWithFormsDesigner | timeline score: 11 | |
| Jul 29, 2014 at 14:08 | comment | added | tzerb | It sounds like your project has pretty serious communication problems. | |
| Jul 29, 2014 at 13:59 | history | asked | rjzii | CC BY-SA 3.0 |