3 ms·
Often projects need a history of stable checkpoints, and source control is one way to provide that.
by snerbles 11mo ago
Often projects need a history of stable checkpoints, and source control is one way to provide that.
- fragmede 11mo agoYes, but does it need all the ceremony surrounding it? If, every time I saved the file, the changes were analyzed and committed to git, and a useful commit message included, and commits squashed automatically and pushed and tested and tagged (using magic, let's say); if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?
- apsurd 11mo agoautomated commit message will tell you the "what" not the "why". In any circle of "what makes a good commit message and why even do it" discussions, invariably the recommendation is to explain the "why" and leave out the self-evident "what". If your stance is that commit and commit messages can be automated away then we might as well not even have them. I don't share this view, but yeah in this world we don't need AI to do things that shouldn't be done in the first place.
- jes5199 11mo agoincreasingly, the automated systems have access to the original ticket or bug report, and maybe even the conversation while implementation is happening. They can record the “why”
- fragmede 11mo ago> we might as well not even have them. You can't see any value in being able to see the "what" in a short bit of English at a glance vs having to analyze a 300+ line diff to figure out what it's doing?
- satvikpendem 11mo agoUse jujutsu
- Shorel 11mo ago> if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look? They would look like noise. You would be the source of that noise. One commit per edit? Nonsense. Me and any other developer would hate to share a repository with you.