Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you ever truly use your revision history?

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 287 posts

Re: Ask HN: Do you ever truly use your revision history?

#261

Post by thewebcount »

I use it as a reminder of what I did over the last year for performance reviews. I use a date range on the 'svn log' command to see all of my commit messages and which files I changed. I frequently find smaller things I did that I forgot about and which may have had an outsized impact on our work as a team. I can find refactorings pretty easily with it, too.

I've also used it to do some deep archeology. I had a piece of code I inherited that was always problematic. Eventually, I went through its history to figure out what it was originally intended to do and why it changed over the years. This was invaluable for finally figuring out how to fix the damn thing once and for all.

Re: Ask HN: Do you ever truly use your revision history?

#262

Post by thewebcount »

Marsymars wrote: post #193
astura wrote: post #95

Yes, yes, absolutely. I've looked at history going back 10+ years (at least). Many times. Two-year-old commits I consider to be fairly recent. I can't remember a specific reason why off the top of my head, but it was usually something to do with looking at the context around why some piece of code existed. The companies I've worked for also require commit messages to contain bug tracking IDs, which can provide furthe…

> There's also really not much of a reason to migrate from svn to git if svn is still working for your organization. Attraction to new devs. I'm new enough (past decade) to software development that I've only used git/mercurial, and joining a company that required using svn would give me serious pause.

It shouldn't. I've switched version control systems probably a dozen times over the years. There are common features, and of course, unique syntax to each of them. But once you understand how one works, it's not usually too difficult to use others at least at a basic level of getting changes and committing changes.

Re: Ask HN: Do you ever truly use your revision history?

#263

Post by thewebcount »

eterm wrote: post #74
JesseAldridge wrote: post #34

> 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.

It may well be the reason. I don't know the parent commenter but speaking from my own experience I recently tried to migrate a legacy code base from svn to git and the common tools all failed for me. One of them ran for ~72 hours before falling over for "reasons". That was only ~6 years of commit history too. I could imagine 30 years is a whole extra logistical challenge. Not to mention making sure the whole develope…

Same. We have a 20 year old code base we migrated from Perforce to svn about 10 years ago. Now they want to migrate to git. Unfortunately, we can't get it to work either. Same thing - after many hours of running it just fails with typical useless git messages that nobody comprehends. It's quite frustrating.

(And personally, I hate git. I've used it professionally, and while it works, it's very difficult to use compared to svn or p4. Between it's utterly incomprehensible made-up terminology and horrid syntax, and hashes for commit numbers instead of just an incrementing integer, it's quite a bit less useful than svn was for us. But it's being forced on us, unfortunately.)

Re: Ask HN: Do you ever truly use your revision history?

#264

Post by ScottBurson »

simias wrote: post #160
goatlover wrote: post #86

Earlier quoted context omitted.

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…

I used to be one of the "old guys" fighting against git because subversion is "good enough" and I didn't want to relearn a new tool. I finally had to learn git because a project I contributed to made the migration and I could no longer postpone it. I'd never, ever, go back. At this point I'd go as far as saying that git is objectively superior to SVN because it does everything SVN can and then more. One caveat being…

SVN has its limitations, but having used Perforce in my last job and now using Git, I wouldn't mind going back. It's a judgment call, as the two systems have different strengths and weaknesses, but I don't find Git to be an overwhelming improvement. For instance, in Git, if you merge from branch A to branch B while work is underway on both, then merge A to master — and assuming you're using squash merges, as is pretty much essential to get a readable commit history — and then merge from master to B, you're in merge hell, because Git doesn't remember that the squash-merge commit contains some of the changes that were already merged to B. Perforce gets this right: it gives you an equally clear master history, with a single merge commit each time you merge from a branch, but doesn't lose the relationship of that to the individual commits in the branch.

Re: Ask HN: Do you ever truly use your revision history?

#265

Post by atomicity »

Ozzie_osman wrote: post #178
personjerry wrote: post #169

Earlier quoted context omitted.

I agree code history can be used as a form of documentation, but in cases like this looking through years of code to find the decisions/reasons leading to a particular design seems like inefficient communication. It seems like "real" documentation with a few sentences explaining directly would be more suitable.

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 just having a design doc. If I'm troubleshooting a production bug, then the granularity the commit log offers becomes important enough to offset its slow "query" speed, so I'd want enough "why" commits in the commit log and outside of people's heads.

- People write to the commit log without a well-defined "schema". If you use something like tags, how do you handle changes to the tags ("schema evolution")

This is my train of thought for why I lean towards "why" comments near the code or in a design doc over commit messages, which I allow to be a more sloppy.

A higher-level thought: The attractiveness of the event sourcing analogy often comes from assuming that the commit log should be a strongly consistent source of truth. However, it's good to remember that a huge amount of info about the code is stored in the team members' heads. In particular, the code writer knows a huge amount that can't be easily documented. So an alternative analogy would be to think of each member as a VM attached to block storage. If a VM fails (the person gets sick) or leaves the cluster (they leave the job), then you lose all of the data in block storage. So, the team wants to facilitate just enough overhead/admin work to transfer important data from individual team members to shared but slower storage (like the commit log, design doc, comments, etc.)

Re: Ask HN: Do you ever truly use your revision history?

#266

Post by twic »

james_s_tayler wrote: post #251
twic wrote: post #227

Earlier quoted context omitted.

I 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.

As 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?

It 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.

Re: Ask HN: Do you ever truly use your revision history?

#267

Post by bacon_waffle »

yokohummer7 wrote: post #126
bacon_waffle wrote: post #24

We just switched from Perforce to git at work, and about the first 2/3 of a project I work on got squashed together. It took me less than a week to bump in to that "initial commit" when trying to figure out why a bit of code is the way it is. "git blame" (or the p4 equivalent) is my usual archaeologic tool in this context, but "git bisect" has been very helpful in others. For the first, it should be easy to look at y…

I'm in a similar boat with you, so I have a few questions: 1. Why did you switch? Are you satisfied with the new experience? 2. Why was some of the history needed to be squashed? Were there any technical concerns?

1a) I wasn't involved in the initial decision to switch, but gather it came down to expense and some unsupported perforce-related tooling.

1b) Absolutely! The switch from p4 could've been smoother, but git and access to the associated ecosystem is far ahead of Perforce for everything except storing binaries. We've been abusing p4 by storing electronics CAD files and similar, and do need to put some effort in to a new solution there. For source code, git (and the ecosystem of modern tooling it gives access to) is a huge improvement over p4.

A particular improvement has to do with network latency. Working from halfway around the world, I notice that p4 operations involving many files are very much slower than the similar git operations.

2a) I wasn't involved, but the particular project mentioned above had moved within the depot at some point, so guess the conversion tool that was used to move it couldn't manage that move. I intend to rebuild the older history in git, then see how viable it is to use git-replace to stick it on the beginning of what we have now.

2b) Yes. However, nontechnical concerns dominated conversation by far - to the detriment of the technical concerns.

Re: Ask HN: Do you ever truly use your revision history?

#268

Post by mandeepj »

bonestamp2 wrote: post #177
a1studmuffin wrote: post #129

Hell 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…

"What was changed is easily seen in the commit itself, why needs to be in the commit message."

Commit message is like subject of an email. Is n't it faster to look at commit message, and get an idea about change rather than go through commit and understand it?

Re: Ask HN: Do you ever truly use your revision history?

#269

Post by bonestamp2 »

mandeepj wrote: post #268
bonestamp2 wrote: post #177

Earlier quoted context omitted.

> 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…

"What was changed is easily seen in the commit itself, why needs to be in the commit message." Commit message is like subject of an email. Is n't it faster to look at commit message, and get an idea about change rather than go through commit and understand it?

Yes, fair enough... having both in the commit message is ideal. I just mean that the absolute minimum is the why because at least the what can be deconstructed from the commit.

Re: Ask HN: Do you ever truly use your revision history?

#270

Post by golergka »

Sharlin wrote: post #206
bentcorner wrote: post #191

Earlier quoted context omitted.

> 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.

Well, the Unreal Engine is 22 years old. I doubt the current incarnation is free of legacy code.

The current version was developed from scratch.
Post reply on HN