Yes. Not frequently, but when sometimes git bisect saves my day. That's why I don't allow rebase or squash in my repos – code's history is valuable information, and I don't want to lose it.
Ask HN: Do you ever truly use your revision history?
271–280 of 287 posts
Re: Ask HN: Do you ever truly use your revision history?
#272Earlier quoted context omitted.
> I find the temporarily localized documentation idea quite interesting – anyone else here tried that? I've done this a bit. For several of my $DAYJOB projects I maintain documentation as Markdown files in the project, which get rendered into a website at build time. The project changelog is kept in version control the same way ( https://keepachangelog.com ). Several times I've tried an experiment or alternate approa…
Thanks for sharing! I'm not a big fan of changelogs, personally, except for publicly released projects. I prefer to have workflows that use version control for this. Reverting on master, but tracking the prototype in the changelog is a nice hack, but has a cost in terms of clutter, ability to bisect etc. I think I would prefer something branch based, but I haven't yet properly thought about the best way of doing it.…
I think as the number of branches grows, people will just start to drown in the huge list of unmerged branches and will start to work as if only trunk/master exists.
With a text file that summarizes all the project's main line of history in a structured, linear way, it's very simple to extract just what you're interested in or find all the entries for a particular thread of research across history, quickly.
I don't think the tooling around git branches really enables that kind of operation in a quick, easy way, partly due to the inherent nature of branches.
I'd be interested to see what your hypothetical workflow turns out like in practice, though. It's certainly possible I'm just not seeing the potential.
Re: Ask HN: Do you ever truly use your revision history?
#273> they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
Maybe the old guys didn't think there was a good reason to switch from SVN to git, if SVN had been working for them. It sounds like switching just because git became more popular. Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason…
> But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.
I went through periods where I had to use CVS, then SVN, and then git. The transition period between each one was a little problematic since I had to constantly refer to the documentation in order to learn the new source control commands, but, in my opinion, one should be capable of learning new technologies.
Re: Ask HN: Do you ever truly use your revision history?
#274From 2007 forward (1,2,3,4,5,6,7,8,9,10 companies I've gone through) when using git, developers looked at the history infrequently. A couple times in the (#6 company) where we spent 3 years to create a js framework from scratch and a mobile web offering of the HUGE office toolsuite. Most of the time, it was to back out changes or bisect, which requires a revision history. You almost never need it, until you do, mostly for local and your own branches. Features tagged in commits with JIRA support covers the vast majority of needs. Extended comments are useful to explain individual goals for the commit that make up the feature.
Re: Ask HN: Do you ever truly use your revision history?
#275Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information…
> I'm in AAA gamedev and the codebase I deal with goes back 20+ years. I'm curious what parts you work on (engine/tooling?). I've always had the impression that games usually have more throwaway code than other types of applications.
Until the OP mentioned Perforce, I was 100% sure they were a co-worker of mine. I also work on a 20+ year old project, mainly on the core graphics/game engine. It’s mainly used to power a single game franchise, although I’d say that any commits from more than 2 major versions ago aren’t all that useful anymore. Too many things keep changing especially around the area that I work on.
Re: Ask HN: Do you ever truly use your revision history?
#276Earlier quoted context omitted.
I disagree. In some cases, code history can be much more efficient. You really need a mix of both. There will be things that are much better captured as part of a revision/commit, especially if your commits are well-designed, grouped into logical chunks, and include messages themselves (and maybe are linked to a project management tool). You will need information like "this code was added as by X as part of work they…
Capturing most of your data in your commits/revisions seems to suffer from a lot of the unsolved event sourcing issues: - How do I quickly find the info that I want? How do I "query" the commit log? Often times, we want a "view" of the history which tells us specific info. If I need to scan through half of the commits just to get a good understanding of the architecture of the code, then that's more wasteful than jus…
I recommend checking out Peter Naur's essay "Programming as Theory Building"[0] as it touches on the subject of a program being more than the code + documentation, it lives on its designers' and developers' heads, their intents, visions, etc.
Re: Ask HN: Do you ever truly use your revision history?
#277Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information…
> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. So true, we have this one senior developer who gets mad if someone's algorithm isn't as efficient as it could be (fair enough I suppose). But we can't get him to use commit messages that are more than 1-3 words and simply mention a word or three about the area of code that was changed. Years late…
I wonder why is it so hard for people to right good commit messages. At my company I've actually tried trying talking in-person to people, even write a doc explaining the benefits and how to do it, pointing people to good resources like this one: https://chris.beams.io/posts/git-commit/
And still, I can't get people to do it. I find it so valuable to look at commit messages that are written, that explains the why behind the changes in the commit but can't get people to see the same value as I do. Any tips on that? Would be really appreciated. :)
Re: Ask HN: Do you ever truly use your revision history?
#278Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information…
> I'm in AAA gamedev and the codebase I deal with goes back 20+ years. I'm curious what parts you work on (engine/tooling?). I've always had the impression that games usually have more throwaway code than other types of applications.
Could easily be a sports game. That was my guess, then I remembered that the quake engine powered Half Life 1 forever. Could possibly also be working with the iD engine?
Re: Ask HN: Do you ever truly use your revision history?
#279Yes, I use it heavily. The further back in time I go, the more valuable the revision history is.
Where I work, we use it primarily as part of maintenance. Looking through what changes have been made to a section of code over time very often gives insight into what is causing a current malfunction -- sometimes it even lets you spot the problem almost immediately.
We also use it as part of development and bug tracking. All code changes are tracked by revision number. Even there, being able to look up even antique history can be very useful.
Re: Ask HN: Do you ever truly use your revision history?
#280Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information…
> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se.
Oh, so much this! The same applies to in-code comments. If your revision notes (or your code comments) are only telling me what I can plainly read in the code, then they're utterly pointless. Tell me what I can't read in the code: the "why"s, as well as potential consequences and "gotchas" the changes may present.