4 ms·
Yes, but maybe not in the way that you're thinking. The scenario isn't "I'm gonna go browse the changes that were made in March of 1994", instead it's trying t
by rictic 7y ago
Yes, but maybe not in the way that you're thinking.
The scenario isn't "I'm gonna go browse the changes that were made in March of 1994", instead it's trying to solve a specific mystery.
You see some code that doesn't make much sense, so you look at git blame to find the commit where it was written. Look at the full change, read the commit message, and now you've got some more context. Often this is enough to understand, but if not, you can check out the code at that time and read the implementation of related systems. Soon things are starting to make sense! Certainly they make much more sense than they did when you started.
- tracer4201 7y agoYou hit the nail on the head. The code review tool at my company links together all the commits that were in that code review, when there’s more than one package, I mean. It’s super helpful to look at what all was changed across packages and understand how the code base evolved.
- chucksmash 7y agoI love reading through revision history but it's so, so easy to mess up given people and time. We have a long history spread across several different (generations of) SCMs. I see each of the following quite often: Most recent revisions (version A, code comments date code to the 90s): - 2011-02-03: Migrate to git - 2008-01-12: Migrate to SVN - ~Fin~ Most recent revisions (version B): - 2018-12-12: Split <X> out into own file - ~Fin~ Most recent revisions (version C, sweet monorepo blogpost edition): - 2019-10-01: Create monorepo for <Team/Superteam/Division> - ~Fin~ --- It's hard to do transitions between SCMs (or between repos) right. For instance, when you follow the recommended steps for moving to a monorepo in git, the history is maintained but not shown in GitHub. It's so easy for well meaning people to destroy history or make it inaccessible for practical purposes when cleaning up dead code, reorganizing code, etc. Even if the history is still maintained (e.g. if there was a file rename in the same repository, you could use git log --follow, if you're trying to find when a particular snippet first came into existence, you can use git log -S<snippet>) but practically as soon as I run into one of the above, that's the end of the line.
- twic 7y agoI once worked on a codebase where almost every mystery in the code could be traced back to a commit "Moving TIM one level down", and no further.
- tempanonforaday 7y agoOh boy, library levels. "How are we almost level 100 now? We're going to need an exemption soon!" "We'd better go move around some orphaned, 20 year old C code to avoid triggering this well-meaning organizational policy!" I was sure you and I must have worked at the same company. Alas, TIM isn't named TIM here though.
- james_s_tayler 7y agoAs in there was a terrible developer named TIM that caused all the problems in the code and the solution was to move him to the basement and assign him to non-coding tasks, so no one ever heard from him again?
- twic 7y agoIt could be. I would have said that the reason was that the name of the software was the TIM, and at some point, the repo had been restructured so that the code for the main app was in a subdirectory rather than in the repo root, but that could easily have been a cover story. EDIT Ah no, it couldn't have been that, because i met several of the developers who had caused all the problems in the code, and none of them were called Tim or in a basement.
- magicalhippo 7y agoIndeed. I'm guessing I use the revision history several times a week. We have a complex code-base, often you'll want to check why something was written a certain way, so annotating and checking commits, and possibly the referenced JIRA issues gives that context.