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

321–330 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#321

Post by pdimitar »

emn13 wrote: post #318
sangnoir wrote: post #269

Earlier quoted context omitted.

Sure, I can - but should I? That's the fundamental difference in opinion (which I don't think can be reconciled). I don't need to know what the developer was thinking or follow the individual steps when they developing a feature or fixing a bug, for me, the merge is the fundamental unit of work, and not individual commits. Caveat: I'm the commit-as-you-go type of developer, as most developers are (branching really is…

But the problem with this approach is that you're making it impossible to extract the actual changes when you do want them, whereas simply skipping non-merge commits is a minor inconvenience (`--first-parent` tends to cover it). I mean, granted, it's not ideal. I think this is a bit of a problem with the low-level nature of git - Ideally it'd be easier to semantically bundle such sequences of commits such that it's b…

> when you merge via squash, what kind of commit messages do you retain? Do you mostly concatenate the commit messages, or rewrite the whole thing?

Context-specific. For a bigger PR that deals with an extensive refactor I'll prefer to have a descriptive title and hand-curated task list below (so definitely not 1:1 to commit messages). For smaller PRs -- or more focused ones, like those dealing with a single feature or bug -- I'll only leave a descriptive title.

But I usually never leave a list of commit messages. Not because I have no discipline; sometimes some refactoring requires 4-5 steps and all commits have 99% identical messages which is not useful when you aggregate those in a single list of bullet points in the end.

---

> But the problem with this approach is that you're making it impossible to extract the actual changes when you do want them, whereas simply skipping non-merge commits is a minor inconvenience (`--first-parent` tends to cover it).

Again, that's not the issue here. The issue is that when you work on a big project (like many of us do) you get something like 4-7 merged PRs a day; don't pull/fetch for 3 days and you'll get 60+ lines in your terminal when you get to it.

There are people who manage releases and people who chase subtle regressions. Having git bisect narrow it down to a big PR squashed commit is actually a win; it gives them a localized area inside which they can work with other tools (not bisect).

In the end I suppose we can say it's a subjective taste. But I always appreciated the main branch's history to only consist of squashed commits. Again, it gives you a good bird-eye's view.

Re: Althttpd: Simple webserver in a single C file

#322

Post by pdimitar »

coldtea wrote: post #195
plorkyeran wrote: post #175

Earlier quoted context omitted.

Storing every single version of the file which ever hit disk locally on my machine in the history would be the most accurate, yet no one seems to advocate for that. Even with immutable history, which versions go into the history is a choice the developer makes.

> Storing every single version of the file which ever hit disk locally on my machine in the history would be the most accurate, yet no one seems to advocate for that. You'd be surprised. It's only because we understand (and are used to) tool limitations (regarding storage, load, etc) that we don't advocate for that, not because some other way is philosophically better. I'd absolutely like to have "every single versio…

I'd be very surprised if you used such a feature on a daily basis indeed.

I understand the rationale but the balance tilts too far into the "too much details" territory for me and that can slow me down while digging.

What I found most productive for myself is that searching for a problematic piece should happen on a two-tiered tree, not a flat list. What I mean is: first find the big squashed PR commit that introduces the problem, then dig in more details inside of it.

Not claiming my way is better but for almost 20 years of career I observed it was good for many others as well, so I am not exactly an aberration either.

To me a very detailed history is mostly a distraction. Sure `git-bisect` works best on such a detailed micro-history but that's a sacrifice I am willing to make. I first use bisect to find the problematic squashed commit and then work on its details until I narrow down the issue.

Re: Althttpd: Simple webserver in a single C file

#323

Post by pdimitar »

emn13 wrote: post #254
coldtea wrote: post #195

Earlier quoted context omitted.

> Storing every single version of the file which ever hit disk locally on my machine in the history would be the most accurate, yet no one seems to advocate for that. You'd be surprised. It's only because we understand (and are used to) tool limitations (regarding storage, load, etc) that we don't advocate for that, not because some other way is philosophically better. I'd absolutely like to have "every single versio…

I mean, this isn't even really all that far-fetched, other systems do work like that, such as e.g. word's track changes or gdoc's history - or even a database's transaction log. And while those histories are typically unreadable, it is possible to label (even retroactively) relevant moments in "history"; and in any case just because a consumer-level wordprocessor doesn't export the history in a practical way doesn't…

All of that is completely valid and I appreciate it. But you are addressing a group of people most of which are already overbooked and have too much on their plate every day. How viable is it to preach this approach to them?

Re: Althttpd: Simple webserver in a single C file

#324

Post by pdimitar »

jiofih wrote: post #255
chousuke wrote: post #214

Earlier quoted context omitted.

Typo commits and the usual iteration during development isn't "accurate history". Noise in commit logs provides negative value. Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list; whether it's a single commit that was perfect from the get-go or fifty that you had to re-order and rewrite twenty times does not matter at all; the final commit message should contain an…

Patch-perfect commits are an idealistic goal. The truth is that, as already mentioned, many of those typos and “dirty” commits can be the source of bugs that you’re looking for. Hiding them hides the history.

> 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 love my messy history! But after I nail the problem and introduce the feature I'll absolutely rewrite history so the squashed PR commit simply says "add feature X" or "fix bug Y".

Re: Althttpd: Simple webserver in a single C file

#325

Post by pdimitar »

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.

That's not realistic at all. Programmers are often times "in the zone" and having to craft perfect messages while you're rushing on to the next problem is killing productivity.

Compromises with human nature must be made. Hence -- we need to be able to rewrite history.

Your academic purism is out of place, dude. Real humans don't work like you say they do. Some do -- most don't.

Re: Althttpd: Simple webserver in a single C file

#326

Post by pdimitar »

user-the-name wrote: post #319
azernik wrote: post #315

Earlier quoted context omitted.

In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.

But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.

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.

Re: Althttpd: Simple webserver in a single C file

#327

Post by user-the-name »

pdimitar wrote: post #324
jiofih wrote: post #255

Earlier quoted context omitted.

Patch-perfect commits are an idealistic goal. The truth is that, as already mentioned, many of those typos and “dirty” commits can be the source of bugs that you’re looking for. Hiding them hides the history.

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

Re: Althttpd: Simple webserver in a single C file

#328

Post by user-the-name »

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

Earlier quoted context omitted.

But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.

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?

Re: Althttpd: Simple webserver in a single C file

#329

Post by rpdillon »

networked wrote: post #166
henvic wrote: post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

Fossil has enough wiki and theming features to power a customized website and to let you edit its contents in the browser. I've joked that Fossil SCM is secretly "Fossil CMS". My personal website, https://dbohdan.com/ , is powered by Fossil. A year ago I was shopping for a wiki engine, didn't love any I looked at, and realized I could try something I was already familiar with: Fossil. It did take a few hacks to make…

I'm glad others are using Fossil this way as well! I use Fossil for hosting my small projects, but have also built a forum/wiki site for my family using it, and I'm working on porting my blog to Fossil as well. I'm very impressed with its design and flexibility while still remaining small, fast, and understandable.

Side note: I've been exploring the ecosystem around Fossil/SQlite as well. I've been working with Pikchr a lot recently as a way to create diagrams that can be version controlled. Because Pikchr is implemented as a single C file, I was able to compile using Emscripten as a WASM file, and embed that file in a single HTML page that gives me a "live editing" experience (basically I call a render method when the text area gets updated). The way these pieces of software are written minimizes dependencies and allows for them to be used in a huge variety of environments. I've really enjoyed working with them.

https://pikchr.org/home/doc/trunk/homepage.md

Re: Althttpd: Simple webserver in a single C file

#330

Post by azernik »

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?

1. Waste of code reviewers' time

2. Waste of later coders' time when running git blame on a line when trying to figure out the purpose of code

3. Waste of later debuggers' time when they need to decide whether this error is the thing they're looking for, an unrelated error to bisect skip, or an unrelated error in possibly-related code that they need to manually fix and then re-test.

Post reply on HN