| ▲ | feelamee 4 hours ago | |
> Small PRs were never asked for because they're easier to write, it's always been for the benefit of the reviewer I think they were asked before AI and even they were not easier to write. Its same as with commits. Usually when implementing a new feature I'm just in flow, so I don't think how to properly separate changes to different commits. I mean - not always, but usually maintaining git history in a beautiful and clean manner was extra work even before AI. | ||
| ▲ | esikich 4 hours ago | parent | next [-] | |
Yeah the one and only time I attempted an open source PR, it was for a performance improvement for one small part of the software but touched a zillion files. After looking at the PR I decided not to submit it because it just looked like a mess and I didn't really know how to split that sort of thing up at the time. AI might make this sort of thing more common, but it's certainly not new. | ||
| ▲ | skydhash 3 hours ago | parent | prev [-] | |
Then you may need to improve your git-fu (or $vcs-fu). I use magit, so it's always easier to select only the lines/hunks/files that is for one specific change, stage and commit that. Before magit, I use sublime merge, Intellij vcs feature, and fugitive. My flow state is for editing files. Once that's done and I've got something that work. It's always easy to convert those into sensible commits. Do not that the logs is not the like of "write database schema * add the index page * add the details page * add the new object form". They're more like "show the list of objects * allow object creation * show the details of a specific object". Those breaks to create the commits are more natural to the general flow state. | ||