[gorgoiler]

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”.

[arcadianalpaca]

Yeah 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.

[esfandia]

I 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]

> 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]

The 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]

This is more like squashing the commit log messages, and those are typically rewritten not merely concatenated.