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

251–260 of 287 posts

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

#251

Post by james_s_tayler »

twic wrote: post #227
chucksmash wrote: post #225

Earlier quoted context omitted.

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.

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?

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

#252

Post by ibly31 »

hughw wrote: post #246
tempanonforaday wrote: post #235

Earlier quoted context omitted.

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

Whats' TIM?

Telecom Italia Mobile is a customer of ours, that's what I know as "TIM"

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

#253

Post by detaro »

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 guess this is the place to ask: Anyone seen tools that make those jumps/skipping less important commits/... easier? Would be a good feature for a code exploration tool.

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

#254

Post by james_s_tayler »

When you're trying to solve a mystery one of the first questions you ask about a piece of code you suspect might be involved in the problem you ask "what does the commit message for this say?"

It often contains valuable clues.

Less often you will want to know "how has this code changed over time?" or "was the code like this originally, or did it used to look different at some point in the past?"

Commit messages often say why something was changed. Well, good ones do.

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

#255

Post by jdminhbg »

thewebcount wrote: post #217
manaskarekar wrote: post #135

Earlier quoted context omitted.

Chestertons Fence, to put a name to the phenomenon. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

How so? In GP's case, they found that the "fence" really was no longer needed: > Someone cleaned up the lower level library in 2016 or so, but the rounding remained in the upper layer. This is like the opposite of a Chesterton fence, where the reason it was put up no longer exists, so it's totally safe to remove it.

> Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This is the bit that applies.

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

#256

Post by urxvtcd »

Waterluvian wrote: post #200

I used to get irritated that peers made me jump through hoops to collapse commits into singular meaningful commits. Why bother. Nobody looks at history. And then I started looking at history and its invaluable to have particularly when understanding rationale or debugging issues.

There's kind of a vicious cycle here. History is often garbage, because nobody looks at it, and nobody looks at it because it's garbage.

I find one thousand line commits with changes all over the place evil, but have a hard time convincing people that atomic commits are worth the effort. You know, it's not Real Work™.

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

#257

Post by reificator »

thewebcount wrote: post #217
manaskarekar wrote: post #135

Earlier quoted context omitted.

Chestertons Fence, to put a name to the phenomenon. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

How so? In GP's case, they found that the "fence" really was no longer needed: > Someone cleaned up the lower level library in 2016 or so, but the rounding remained in the upper layer. This is like the opposite of a Chesterton fence, where the reason it was put up no longer exists, so it's totally safe to remove it.

Chesterton's fence is not about never changing things.

They followed Chesterton's fence to the letter. They saw something that didn't make sense, and then tracked down why it worked the way it did.

Once they understood the root cause, they examined the environment and discovered that the underlying issue had been fixed. That allowed them to confidently rework the inconvenient behavior into something better.

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

#258

Post by mceachen »

Reason 1: keeping codebases cleaner.

By keeping commits larger-grained (especially if I'm deleting a functional component), it supports deleting with abandon, and follow the "you aren't going to need it" (YAGNI) principle, rather than having large commented-out sections (or worse, large sections of deadwood in your tree). It also allows you to restore it later if you need it again by only reverting one commit.

Reason 2: finding out WTH went wrong.

By having a master/stable branch and a development branch, if anything goes wrong, I can always diff between the branches to see what/how things broke. Sometimes it's a change to a dependency. Sometimes (ok, most of the time) it's a change I made.

This said, I think it's useful to me because I know what's in the history already. I think looking through commits from someone else with a tree that I'm not familiar with is going to be of very limited use, especially because people don't generally provide the critical answer of "why" a change was done in the commit log.

Related #protip: always try to describe why you're making a change in the commit log.

The how of the change is already there: it's the diff. Why you're either making the change or choosing a specific method over another can be invaluable to the Engineers of Tomorrow, and prevent them from a regression due to context loss/tribal knowledge loss.

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

#259

Post by mikewarot »

embersdev wrote: post #201
nitrogen wrote: post #199

At my current company they place a huge value on that history, so much so that they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits. You can convert a repo from SVN to Git with history intact! There's a tool called cvs2svn that I have used to upgrade really old CVS projects to git (it can do git too), and there is also an svn2git. And, I believe there i…

This is the best answer, but even if you didnt want to go through this trouble... just create a new repo in git, lock down svn and assume from that day on, if you need to see older history, go look in svn. Over time the need to look at svn for history will dwindle.

That sounds like a really bad idea. Eventually you'll consider the SVN stuff to be lost, and it'll be impractical to import it later. As all the responses show, that history has real value.. you don't want to lose it.

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

#260

Post by patrec »

NateEag wrote: post #220
patrec wrote: post #124

Earlier quoted context omitted.

I find the temporarily localized documentation idea quite interesting – anyone else here tried that? > Such an approach only works if your system is small, I see no reason why this wouldn't scale if you (and other people working on the same codebase) just maintain individual branches (say "dang-braindump"). Just do exploratory/documentation work on that and cherry-pick, rebase -i or git merge --ff --squash --no-commi…

> 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. If you have a special prototype branch from which you merge in master and do your prototyping, reverting and optionally notes.md there, you might effectively be able to replace the changelog based flow with just doing git log --no-merges --first-parent. What do you think?
Post reply on HN