Live data from Hacker News

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

news.ycombinator.com

171–180 of 287 posts

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

#171
I have it set up (and many do) so I can highlight a bit of code and see when it was created or touched last, who touched it, and usually what ticket the work was done against -- the context of the change. This gives a whole third dimension of understanding a codebase:

* Dimension 1: Code layout (organization) structure

* Dimension 2: Execution (data-flow) structure

* Dimension 3: Evolution (change over time) structure

All three dimensions try to capture some of the intent of the implementer, and understanding that intent is very important when improving upon the work. Along with that comes a perspective on what assumptions the author had. Code last modified 5 years ago very likely had different assumptions than code written last week -- Being able to see which lines in a function came from which era can illuminate things nicely, and that is only scratching the surface of this evolution-dimension.

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

#174
post #51

Earlier quoted context omitted.

I spent a couple months experimenting with p4git to make sure we got a real history imported. They didn’t get every repository right and I made them redo a few, did a few others over again myself. But lately I’ve been delving into some of the early architectural changes, trying to figure out why a bunch of things get loaded and seemingly never used/only used once... and sure enough someone did some sort of single com…

> I want to be able to go back and add notes to commits Interesting idea - how about using tags for this?

Possible. There’s also another feature that several people have pointed out could be used for this purpose but as with so many things in git, it’s not seamless. Might still be worth using though, even if it only helps a few of us.

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

#175
post #19

Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something. One of my favorite tricks is to make a file out of all the changes in the history: git log -p > bigass and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in the…

Along these lines: git-log has a --grep option which returns only commit messages that match a regex, and git-grep searches over revision controlled files like above. >I like to work on small systems and prevent them from becoming large systems. This is very wise!

Similarly, ‘git log -S needle’ will surface all commits with ‘needle’ in the diff.

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

#177

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 later, he also can't remember WHY he made those changes, so I'd much rather work with someone who writes inefficient algorithms that are easily improved at any time than commit comments that are forever useless.

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

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

#178

Earlier quoted context omitted.

Code history is documentation. There are lots of different kinds of documentation: code API level, module level, system level, tutorials, even books in some cases. Revision history is just another one of those levels, and I believe it is the best at capturing the "why"s of systems rather than just the "what"s.

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 were doing on Y, and they also made changes in other parts of the code as part of that". That context is really valuable.

You can think of it like event sourcing, which captures a lot more information than traditional mutation of data, and as a pattern, is a lot more rock solid... except event sourcing for your data is (usually) much more difficult to implement in practice, and code revisions are already an almost completely solved problem.

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

#179

Earlier quoted context omitted.

Code history is documentation. There are lots of different kinds of documentation: code API level, module level, system level, tutorials, even books in some cases. Revision history is just another one of those levels, and I believe it is the best at capturing the "why"s of systems rather than just the "what"s.

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.

You might find some weird hack in codebase that isn't obvious what it does at the first glance. This isn't something that people document in official documentation but even finding a JIRA ticket that is linked with that specific commit can help tremendously.

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

#180
post #149
post #131

Earlier quoted context omitted.

> There's also really not much of a reason to migrate from svn to git if svn is still working for your organization. But also not much reason against, given the quality of migration tools. The toughest nut to crack is the absence of that handy incrementing version counter.

The issue with the migration is the references (commit IDs) and the fact that branching best practices differ dramatically.

But merging is not a half-baked shitshow.
Post reply on HN