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

221–230 of 287 posts

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

#221

Post by testplzignore »

yardstick wrote: post #36

Our codebase is around 20 years old and was in CVS, then SVN, then git. Then several years after git, a new git repo without any history due to poor use of the first git repo (someone added binaries, bloated the repo to GBs instead of maybe 200-300MB, which made git export horridly slow). In all the steps we preserved the commit history, except for the final git->git. However also when we moved from SVN to git we kep…

> git blame was nice, until someone reformatted the entire codebase

We have a few "blame walls" in our codebase like this due to formatting changes or badly-implemented restructuring/renames. When I'm in bitbucket tracing back through the history of a particular line, I end up having to manually jump back a few commits at certain points in time, and then if the file was renamed I have to also navigate to its old location/name.

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

#224

Post by tracer4201 »

rictic wrote: post #212

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

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

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

#225

Post by chucksmash »

rictic wrote: post #212

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

I 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 out into own file

- ~Fin~

Most recent revisions (version C, sweet monorepo blogpost edition):

- 2019-10-01: Create monorepo for

- ~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) but practically as soon as I run into one of the above, that's the end of the line.

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

#226

Post by kazinator »

There is less value in old commits, but you don't know which one will prove valuable, so all of them have to be there.

2019 fix, of a 2011 breakage:

http://www.kylheku.com/cgit/txr/commit/?id=3a91828748385d8d6...

2020 removal of 2009 misfeature:

http://www.kylheku.com/cgit/txr/commit/?id=24bd936a9fa671599...

The TXR project only goes back to 2009.

We can fix these kinds of things without reference to the past, but the process would feel uniformed and impaired.

Not everything is in the code; there are sometimes questions of requirements, which are not always properly captured in documentation.

We need all the historic questions to be able to figure out the whole situation: what happened to the requirments as well as the code, and how it all relates.

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

#227

Post by twic »

chucksmash wrote: post #225
rictic wrote: post #212

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

I 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 out into own f…

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.

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

#228

Post by Forge36 »

Yes: I used it last week to source a problem we've had since 2012. It helped rephrase our discussion about how it was missed, why it was introduced, add discuss why it sat in waiting for 8 years.

More importantly: we have a clear date in this case for what versions we need to considering releasing patch fixes.

In some cases this can be useful: even when the functional problem it causes is not easily evident in previous versions.

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

#229

Post by dtech »

chucksmash wrote: post #225
rictic wrote: post #212

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

I 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 out into own f…

I suspect that if the industry ever moves away from git in the next 5-20 years, it will be because there's another SCM that has this capability.

Just like DVCS "solved" branching and merging, following history through renames, splits, and other structural will make SCM 2x better.

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

#230

Post by taeric »

derwiki wrote: post #175
bacon_waffle wrote: post #35

Earlier quoted context omitted.

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.

Yeah, the grep option is on the log messages. Use -G if you want the regex in the diff.
Post reply on HN