61–70 of 106 posts
Would also be cool to generate commit messages while viewing history, it could really do a good job of orienting you. I'm imagining "human commit msg | gpt commit msg" so you can look at both. It's a little simplistic right now, kinda just describes the diff, but GPT-3.2 could rock.
Earlier quoted context omitted.
> … and those who tag you as a reviewer on +8,298, -1,943 commits/PRs with the commit message "JIRA-PROJ-84138". At my workplaces, we've told people who do this to break up their larger commit into smaller ones before reviewing. If they haven't done that initially, well, their life is going to get harder for a few days.
Say hello to a long list of smallish commits full of random, unrelated changes and with commit messages "fixed various small issues", "continued implementing ", etc
Earlier quoted context omitted.
> Ideally we want to describe why we've changed it but this information isn't always available I struggle to imagine situation in which this is the case. Surely, even in the worst case of you being told to make a particular change with no explanation given, you can at least drop a "increased from 5 at a request of ${name of your boss}", or "increased from 5, see ticket #${ticket number}" in a comment, and/or a commit…
Something that's standard at the company I work for is commit messages always having the ticket number at the start, and it helps figure out why something was changed so much more than a commit message. Ex of a recent change I saw, but anonymized a bit. PROJ-12345: Added preview flag to video player PROJ-12345 in Jira: When a preview of a video is playing in the persistent player, preroll ads will display on app laun…
Bug: #12345
Closes: #12345
See https://git.wiki.kernel.org/index.php/CommitMessageConventio...
Be more impressed if I write the commit message and GPT writes the code than vice versa. If I wrote the code, writing a commit message is trivial.
Earlier quoted context omitted.
There is a third type of coder: one doing commits with single, obvious, minimal purpose, that still sometimes end up being +8,298, -1,943 - but with a sensible, detailed message explaining what's being done and why. This happens in environments where it takes hours for CI to let your change pass, making small commits prohibitively expensive in terms of time and infrastructure. (And yes, I know the answer is: make it…
And then there are the cases where the diff is a single line, but the commit message over a hundred lines because the change (or more likely its justification ) is not obvious.
I've never seen a 1:100 code to commit message lines ratio so far, but I've seen a few 2-3 line changes with a paragraph or two long explanations. I cherish those. Same if the explanation is in a comment. In fact, if I spot something like this, I tend to praise it publicly on the team chat.
I had one case where a single weird line added much earlier messed up a seemingly unrelated piece of code I've been developing. It took me a while to figure out that something is emitting compiler flags that, with surgical precision, prevent the very thing I was attempting - and then find it nested deep in the build configuration. At that point I wanted to strangle the person who put it there - but a paragraph of commentary attached to that line, plus some extra context in the commit message, made me change my reaction to "oh. OH. I see the point now.", and I ended up commending the author instead.
Earlier quoted context omitted.
Heh… there are really two types of coders. Those who things commits should have a single, obvious, minimal purpose, and who will split off unrelated changes into separate commits… … and those who tag you as a reviewer on +8,298, -1,943 commits/PRs with the commit message "JIRA-PROJ-84138".
> … and those who tag you as a reviewer on +8,298, -1,943 commits/PRs with the commit message "JIRA-PROJ-84138". At my workplaces, we've told people who do this to break up their larger commit into smaller ones before reviewing. If they haven't done that initially, well, their life is going to get harder for a few days.
Neat concept, but this opens up a can of worms for corporate security. Pretty sure I won't get approval to submit proprietary code to a third party service just because I was too lazy to write a few lines of text. Might be helpful to open source projects?
Just add fully homomorphic encryption. I agree with you, but I'm assuming this could just send a diff and that context would be small enough to not leak. Then again, if GPT can keep track of all the diffs...
Earlier quoted context omitted.
> purely functional transformation of the code, adding zero information I mean, a human brain is arguably also a purely functional transformation adding zero information.
It's not. The diff, which is the sole input to GPT-3 here, does not carry the causal context - that is, why the change was made. Nor does it carry the broader understanding necessary to summarize the what succinctly and accurately - things like high-level design terms that mostly exist on diagrams or in issue trackers, but not in the code itself. By adding those details in a commit message, the author can add extra i…