
Ask HN: Why do we have to comment each commit? - z0mbie42
Hi,
I&#x27;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...)<p>Furthermore we can empirically see that commenting each commit is not easy &#x2F; carefully respected.<p>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&#x27;t have other ways to save work!<p>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 ?<p>The workflow would be:<p>You connect to server (repo), then each file modification is automatically sent to server (and broadcasted to other users who have the file open).<p>We keep the branches systems and then atomic merges (and comments) are only made on a merge (pull) request.
======
towaway1138
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.

~~~
z0mbie42
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

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

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

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

------
Memosyne
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](https://github.com/atom/xray/tree/master/memo_core)

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

------
rcfox
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!

~~~
z0mbie42
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

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

