Ask HN: Why do we have to comment each commit? | Hacker News Reader

Ask HN: Why do we have to comment each commit?

3 pointsz0mbie4211 comments

Hi, I've been thinking of ways to improve developers workflow and it appears that we, software developers, are the only one who still have to manually save (commit) our work every x minutes. All other industries have systems with live collaboration and saves (Google docs...)

Furthermore we can empirically see that commenting each commit is not easy / carefully respected.

The important thing is that for me, merge requests are a better concept to describe a single, atomic, conceptual change rather than commits, which are often used as a mean to save work, because we, as developers don't have other ways to save work!

Do you see limitations to a New Generation Version Control with live updates and the only comments you have to make are to create a merge (pull) request ?

The workflow would be:

You connect to server (repo), then each file modification is automatically sent to server (and broadcasted to other users who have the file open).

We keep the branches systems and then atomic merges (and comments) are only made on a merge (pull) request.

There's nothing wrong with producing a series of personal commits with little or no comment, and then squashing them into fewer or a single commit before merging.

But it's very important that the final product have a good comment. What was changed and why? We need to know.

In my proposition, the flow:

1. commit 2. squash commits to a meaningful commit 3. merge

would become:

1. code 2. merge with a meaningful commit

That is basically how Chromium's development workflow goes. Instead of 'merge' we have 'git cl upload' (and subsequent code review and eventual committing/merging). All of your local commits and revisions are landed as a single squished commit in the main repo.

Interesting. In general this seems good, but sometimes I really do want my final submission not to be squished, e.g., because it consists of several distinct stages and is easier to understand that way.

Very interesting, I'll explore this workflow

Your merge centric workflow is perfectly good and valid. But i think a commit message is still good to capture what's going on in your mind when you checkpoint.

Don't listen to people telling you to squash, either. Git will bite you in the ass when you inevitably mix rewritten branches with non-rewritten ones, it's error prone. And rewriting loses history.

I think what your suggesting is similar to Memo[1] which is being developed at Github.

1 - https://github.com/atom/xray/tree/master/memo_core

Thanks, I wasn't aware, I'll explore this project!

You could pretty much get that workflow by putting your repo in a Dropbox folder, just no live collaboration.

Good luck compiling at any given moment when 10 other people are changing files under you though!

Using dropbox looks like a dirty workaround (why designers would use sketch + dropbox instead of Figma ?)

But you raise a very interesting point concerning compilation

But what if you need to find a specific change that happened during an entire development day?

Reply on news.ycombinator.com