
Ask HN: Why don't programming languages have special “commit comments”? - amichail
Upon a commit, these &quot;commit comments&quot; would be automatically combined into a single commit comment.<p>After the commit, the &quot;commit comments&quot; would be automatically removed from the source code.<p>In this way, you would not need to remember what changes you are committing in order to make up a commit comment. You just comment the code as you make the changes.<p>A special syntax would be used for commit comments so they are never confused with normal comments.<p>Note also that in the case of multiple changes being committed at once, these commit comments would give a more accurate mapping of the individual comments to the code changes they refer to.
======
Nadya
Because programming languages have no awareness of version control. Nor should
they.

This is also exactly what comments for commits through VC's are for. If you
are changing a large amount of code in one commit you should rethink whether
or not it should be done through multiple commits instead of all at once. If
your code is well commented and your commit message makes sense - the commit
will explain itself.

Unless I'm not understanding what you mean.

------
cauterized
Sounds to me more like a use case for a commit hook than a programming
language feature.

~~~
amichail
If it's part of the language, then it will be supported by all relevant
tools/IDEs.

~~~
detaro
Not really. A VCS doesn't care about _what_ it versions, so I doubt e.g. the
git developers would ever add special support for your language to git. So the
language community would have to maintain wrappers around all tooling anyways.

IMHO a language-independent style to do this would make more sense, since then
the tools could be used for multiple languages.

------
cnvogel
Try to adjust your work pattern to do many very tiny commits, maybe every few
minutes, with a few-words-only commit message. Then, after a few hours,
regroup using “git debase -i”. (Of course before anything is being pushed
where others can see it).

That way you don't forget what all those tiny changes have been for... And
nevertheless have a coherent description of what you did at the end of the
day.

When you really are working on very separate things in parallel (which you
probably shouldn't), work on different branches...

~~~
kspaans
I believe using the squash command while interactively rebasing to turn your
legion of small commits into a single one will automatically append all of the
small commit messages into the final commit message.

------
bonobo3000
It can't be implemented by a language alone, since we have to integrate with a
particular VCS (e.g git).

I prefer to just make commits for really tiny changes so I don't have to a lot
of remembering.

I think this might not be that difficult to hack together though - 1\. Decide
on a comment format thats easy to parse 2\. make a parser that goes through
your source files and pulls out the comments into a file 3\. make a commit
hook (or just cat the file)

------
bmm6o
How big are your commits that you can't remember what all is in them? I always
do a final diff to make sure that everything is production quality (no
forgotten TODOs, etc), so I've just looked at everything I'm committing.

~~~
eecks
Same, I always check every line difference when I commit

------
theaccordance
We could debate the merits of a feature like this, but a more reasonable
answer is that there simply hasn't been a demand large enough to encourage any
languages to add it. Personally, it would add no value to my workflow.

------
ksherlock
Division of labor. Instead of updating every programming language, VCS, IDE,
etc, for a feature nobody else cares about, scratch your itch and write a
script to do it.

