4 ms·
It would be good to see a real example. There’s a sketch of one in the README.md but I’d be interested to see how it works in real life with something complica
by gorgoiler 7mo ago
It would be good to see a real example. There’s a sketch of one in the README.md but I’d be interested to see how it works in real life with something complicated.
> Add users with authentication
> No, not like that
> Closer, but I don’t want avatars
> I need email validation too
> Use something off the shelf?
Someone in this place was saying this the other day: a lot of what might seem like public commits to main are really more like private commits to your feature branch. Once everything works you squash it all down to a final version ready for review and to commit to main.
It’s unclear what the “squash” process is for “make me a foo” + “no not like that”.
- esfandia 7mo agoI imagine you could use AI as well to create a "squash prompt", but verifying using diff that the "squash commit" results in the same code.
- JimDabell 7mo ago> It’s unclear what the “squash” process is for “make me a foo” + “no not like that”. Commit your specs, not your prompts. When a change is correct, any information of value contained in the prompt should be reflected in the spec.
- gorgoiler 7mo agoThe problem I have is that when you squash the code it does the same thing. PR.patch = a.patch | b.patch exec(PR.patch) = exec(a.patch | b.patch) When you squash the spec you potentially do not get the same thing: PR.md = a.md | b.md ai(PR.md) != ai(a.md) | ai(b.md)
- JimDabell 7mo agoThis is more like squashing the commit log messages, and those are typically rewritten not merely concatenated.
- arcadianalpaca 7mo agoYeah the squash question is the whole thing. If your commit history is "do X" -> "no, not like that" -> "closer" then your final commit message is just "do X" with no trace of why certain approaches were rejected. Which is arguably the most useful part of the conversation.