Hacker News Reader

Comment by vemv | Hacker News Reader

Feels like a punch in the stomach.

git.io has its place in the world, namely for creating code comments to Github immutable permalinks (that is, with SHA markers) that would otherwise surpass a conventional column limit, making linters complain.

I probably have created dozens of such comments over the years. Now people following those will find nothing.

Folks at github should really reconsider their position. Don't expect loyal consumers to keep their trust when you suck at your very job - namely keeping an immutable historic record.

View on HN

The hard column limit and linter complaints are in the wrong here. Long, unbreakable strings exist and are reasonable (with URLs generally being the most common, but not the only), and any linter that insists they not exist is bad.

I would also note, for this particular style of URL, that the long URLs are much more useful, as you can read the ref and the path directly, and perhaps thereby bypass the web entirely. The short URL has to be followed to discern its target.

That’s a bit over the top as you did have a hand in choosing to do that and not to fix linters / ignore those self-inflicted problems, instead opting to use a URL shortener and eventually get burned like everyone else who has ever done this. Their job is not to create an immutable historic record. You were never a customer of git.io. The goal was to shorten links because it was trendy.

I've been a Github customer over 10 years.

If you don't see the value of not breaking contracts (in the API sense), it is clear to me that your opinion isn't qualified.

You can't escape the legal reality that you're demanding perpetual operation for no consideration merely by clarifying that you mean "contracts (in the API sense)". That was not part of your contract in either sense. If you wanted it to be forever, you should have paid for it.

Any plan that assumes a service won't eventually go out of business is a bad plan.

Don’t most URL shorteners die in under 10 years? I see the value of not breaking API contracts, but some services are more known for breaking their contracts than others.

After a couple of issues with broken links in code comments, I think the best approach is to link to an archive for the page in question (if public) since that has the original URL and makes the original content at the time of the link available as well.

Relying on a cloud-based third party link shortening service is a creative solution to your linting errors, to say the least!

No. Use your own URLs or face the very obvious predictable consequences. There is absolutely no reason to add another layer of redirection just to get around your 2-bit linter config.

That sucks and I know it doesn’t help fix your current situation, but I’ve found it useful to include more context and long comments in commit messages than code comments. If your team knows how to use git blame for archeology, the information tends to stay more cogent to the code, while code comments often go stale.

It becomes increasingly undiscoverable. Especially after some lint rule changes and the last change becomes the lint fix.

Info going stale seems much worse with commit messages since they can’t even be updated unlike comments.

This is largely a problem of GitHub and other code UIs making it awkward to see anything other than the most recent commit in blame view.

With `git blame` you can use `-w` to ignore whitespace changes and `-M` to detect moved/copied code; a lot of the time this will help to rapidly find the relevant commit rather than a lint change.

You can also use `git log` on a range of lines of a file: `git log -L 15,23:src/main.rs` and if you add `-p` you'll see diffs as well.

Comments can go out of date, commit messages (if used properly) provide a genuine timeline of the evolution of the code.

I generally find code comments much more useful than commit messages. They are of course not mutually exclusive and you can (and should) do both.

9 times out of 10, "why are things the way they are now?" is what I'd like to know.

Occasionally, of course, I would like to know "why things were the way they were x commits ago" and that's when commit messages come in handy. But that's the minority use case for me.

Interesting. I'm basically the opposite. I use `git blame` heavily and find that I can rapidly understand the intent behind some code by doing so, assuming the commit messages are well-crafted. Comments are great, where appropriate, but to achieve the same density of information you'd have to add a comment with every commit, which would probably result in a difficult-to-read codebase.

    I use `git blame` heavily and find that I can rapidly 
    understand the intent behind some code by doing so, 
    assuming the commit messages are well-crafted

Me too. Once editors started displaying inline git blame information, it was pretty transformational.

But, this bogs down pretty quickly for me. Great for a single line of code, but if I'm trying to understand something that spans multiple methods or multiple files that's a lot of spelunking around the commit messages, which are a mix of whys and whats.

At their best, code comments are a really focused distillation of the current whys and should never ever contain whats.

It depends on what kind of commit messages your team writes, and how much "churn" a line of code gets with style changes, whitespace, etc. It requires making smaller, focused commits so the comment is directly relevant to the change, and writing good commit messages that tells you why something is the way it is _now_.

I always use `git add -p` to only stage relevant portions of my current work, and then usually write a detailed message like this:

    Decrease reprojection error threshold to 1.0

    With improved calibration, RANSAC has been able to find
    a similar number of inliers even with a tighter
    threshold, resulting in better triangulations.

    <maybe attach some output showing improved reprojection error stats>

Now when someone comes upon

   threshold=1.0

and want to know why this number is what it is, they can get blame it. The latest commit should be enough, but it might also be useful to know why that threshold has changed over the time.

The problem with churn can be mitigated by telling git to ignore whitespace changes, but it's not perfect. Maybe more helpful is to have a style guide and make it part of your review process so you don't end up with multiple developers doing things like reformatting a multi-line function call to their liking over and over.

Interesting, I have always viewed those as very different things.

Comments explain non-obvious things. For example, "this is a custom search because it was found to be 2.3x faster than .find() for this use case" or "this is sent as a string for backwards compatibility with ExternalRandomApi v1.2" or just walk through a complex algorithm.

I typically only go into archeology mode for two reasons:

1) I found the source of a bug and want to see when it was introduced and why. This is most helpful to prevent reintroducing an old bug, especially in old code lacking unit tests.

2) Someone wrote code that should have been commented, but wasn't.

I think JIRA links are a lot better than huge inline slabs of text in commit messages.

Then you can change them later ie make links to other tickets or leave comments.

The first thing I thought of when I saw this comment is that I’d seen it somewhere before: https://xkcd.com/1172/

Reply on news.ycombinator.com