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

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

331–340 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#331

Post by azernik »

jiofih wrote: post #320
azernik wrote: post #308

Earlier quoted context omitted.

Problem is, when you're debugging later on you need to understand what a breaking commit does (or is intended to do) before knowing what it did wrong. Let alone the code review issue. In any multi-person project, it is just as important that your commit history be readable by a third party for information as that it be useful for your own personal debugging.

That’s solved by writing good commit messages from the start. Commiting junk or WIP is an easily fixable culture problem.

Exactly. You should not commit WIP.

By definition the actual history of your work includes WIP, so this means your commit history should not reflect the actual history of your work.

Re: Althttpd: Simple webserver in a single C file

#332

Post by azernik »

user-the-name wrote: post #327
pdimitar wrote: post #324

Earlier quoted context omitted.

> Patch-perfect commits are an idealistic goal. Indeed they are, hence the need to rewrite the history. Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. And to be frank, I am interested in the same, mid-term and long-term. While I am grappling with a very interesting problem for a month then yes, I'd lov…

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. Why would they be looking at the version control system for this? That is not what it's there for.

That is absolutely what it's there for! git blame and git log are extremely commonly used, git bisect is only convenient in a commit history where breakage is uncommon, &c

Re: Althttpd: Simple webserver in a single C file

#333

Post by pdimitar »

user-the-name wrote: post #327
pdimitar wrote: post #324

Earlier quoted context omitted.

> Patch-perfect commits are an idealistic goal. Indeed they are, hence the need to rewrite the history. Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. And to be frank, I am interested in the same, mid-term and long-term. While I am grappling with a very interesting problem for a month then yes, I'd lov…

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. Why would they be looking at the version control system for this? That is not what it's there for.

GitHub in particular is widely used by managers -- not the higher-level managers of course, but a lot of engineering managers have mastered the usage of GitHub issues, Markdown task lists inside PR descriptions, and reviewing results of CI/CD pipelines.

And many tech leads simply don't have the time to review every single WIP commit. They want meaningful message/description of the big squashed PR commit. If you just post a merged list of all commit messages with 10x "fix stuff" inside you'll be in big trouble the next time around and your work will be inspected very closely.

The practices I am describing to you are reality in many tech companies. Writing code there is not about you at all. And almost nobody will read your code and PR descriptions unless they really have to. Hence it's a professional courtesy to make those as small and meaningful as possible.

Re: Althttpd: Simple webserver in a single C file

#334

Post by pdimitar »

user-the-name wrote: post #328
pdimitar wrote: post #326

Earlier quoted context omitted.

It shouldn't for your personal stuff. But it absolutely should when you work in a team. I'll personally scold you if you waste my time with merging a 20 commit PR of which 10 commmits are "fix stuff" or "fix typo" or "oops forgot variable" etc. It won't pass code review. You are free to disagree. I am only telling you how it is in many companies.

But why? What problem are you actually solving with this?

As the other sibling poster says, it's about not wasting other people's time. Make the messages/descriptions ruthlessly short and to the point and your colleagues will like you.

Re: Althttpd: Simple webserver in a single C file

#335

Post by user-the-name »

azernik wrote: post #332
user-the-name wrote: post #327

Earlier quoted context omitted.

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. Why would they be looking at the version control system for this? That is not what it's there for.

That is absolutely what it's there for! git blame and git log are extremely commonly used, git bisect is only convenient in a commit history where breakage is uncommon, &c

None of those require a "meaningful history that tells a bigger story".

Re: Althttpd: Simple webserver in a single C file

#336

Post by user-the-name »

pdimitar wrote: post #333
user-the-name wrote: post #327

Earlier quoted context omitted.

> Managers, tech leads, or users of your OSS project don't care about the "fix typo" comments. They are interested in a meaningful history that tells a bigger story. Why would they be looking at the version control system for this? That is not what it's there for.

GitHub in particular is widely used by managers -- not the higher-level managers of course, but a lot of engineering managers have mastered the usage of GitHub issues, Markdown task lists inside PR descriptions, and reviewing results of CI/CD pipelines. And many tech leads simply don't have the time to review every single WIP commit. They want meaningful message/description of the big squashed PR commit. If you just…

> And many tech leads simply don't have the time to review every single WIP commit

Do you usually review every commit? I usually just review the diff between the PR'd branch and master, as does everyone I work with.

Re: Althttpd: Simple webserver in a single C file

#337

Post by pdimitar »

user-the-name wrote: post #336
pdimitar wrote: post #333

Earlier quoted context omitted.

GitHub in particular is widely used by managers -- not the higher-level managers of course, but a lot of engineering managers have mastered the usage of GitHub issues, Markdown task lists inside PR descriptions, and reviewing results of CI/CD pipelines. And many tech leads simply don't have the time to review every single WIP commit. They want meaningful message/description of the big squashed PR commit. If you just…

> And many tech leads simply don't have the time to review every single WIP commit Do you usually review every commit? I usually just review the diff between the PR'd branch and master, as does everyone I work with.

Exactly, and that's why we use squashed commits.

Re: Althttpd: Simple webserver in a single C file

#338

Post by chousuke »

azernik wrote: post #331
jiofih wrote: post #320

Earlier quoted context omitted.

That’s solved by writing good commit messages from the start. Commiting junk or WIP is an easily fixable culture problem.

Exactly. You should not commit WIP. By definition the actual history of your work includes WIP, so this means your commit history should not reflect the actual history of your work.

I'm of the opinion that you should commit WIP stuff. Use the SCM for managing your source code, damn it!

Just don't publish WIP crap; fortunately, you can have your cake and eat it too, with git.

The biggest reason git (and any similarly advanced SCM) is superior to non-distributed alternatives like Subversion is that I can use it to manage my own workflow, instead of just as the final off-site backup of whatever I decide to publish. I get to actually use everything git offers for shuffling commits and code around while coding.

Want to switch contexts quickly? git commit the whole thing and just switch a branch.

How about untangling a hairy merge? Do it piecemeal and commit when you're done with each bit; it's trivial to then undo mistakes, redo, combine or reorder stuff and you cannot lose any work by accident because git commits are immutable.

All of these features essentially require history rewriting; sure, you're free to rebrand and not call "store WIP state in repository" a commit even though it is one, but I would consider any SCM without these features nigh useless for most work.

Re: Althttpd: Simple webserver in a single C file

#339

Post by user-the-name »

pdimitar wrote: post #337
user-the-name wrote: post #336

Earlier quoted context omitted.

> And many tech leads simply don't have the time to review every single WIP commit Do you usually review every commit? I usually just review the diff between the PR'd branch and master, as does everyone I work with.

Exactly, and that's why we use squashed commits.

Why? You don't need to. GitHub will show you that diff, git itself will show you that diff. There is no need to permanently rewrite history to do this. That makes no sense.

Re: Althttpd: Simple webserver in a single C file

#340

Post by pdimitar »

user-the-name wrote: post #339
pdimitar wrote: post #337

Earlier quoted context omitted.

Exactly, and that's why we use squashed commits.

Why? You don't need to. GitHub will show you that diff, git itself will show you that diff. There is no need to permanently rewrite history to do this. That makes no sense.

For the last time: squashed commits help teams who need the main branch be a high-level history of delivered features and fixed bugs. Where one commit is one delivered feature or a bug fixed. That's the idea.

Whether you think that "makes no sense" is inconsequential. Many people find it very meaningful.

Post reply on HN