This message was deleted.

Ooooh I really like the idea of

v[n]

being transformed into a version diffing link

Thank you 🙂 if you ever implement this, it would be very cool to have

gt submit

print the version, for example:

$ gt ss --restack
🥞 Validating that this Graphite stack is ready to submit...
flupke/foo does not need to be restacked on main.
Restacked flupke/bar on flupke/foo.

✏️  Preparing to submit PRs for the following branches...
▸ flupke/foo (No-op)
▸ flupke/bar (Update code)

📨 Pushing to remote and creating/updating PRs...
flupke/bar: <https://app.graphite.dev/github/pr/flupke/project/1103> (v3)

Yep - I think @Jacob Gold has some tentative future plans to bring versions into the CLI

we actually already have this data in the CLI and as such shouldn't be too hard to surface, cc @Alyssa Baum for viz

thanks for this report! i’ve got a feature that i’ve wanted to build for a while that i finally got around to (should land by eod today) which i think will help here~ inline comments will now show a badge for which version they were left on, and we’ve also added links to view changes before/since that comment in the kebab menu! for your review/fix/… workflow, you can click

view changes since v#

to see what changed since that comment and confirm that the author made the changes that you expect as always, please let us know if you have any feedback or ideas 🙂

Our use case is the reviewer posts all his comments at once, and then the author answers to them one by one, each time by pushing a new version. In your example all the comments links would show v1..v10, but what we want is v1..v2, v2..v3, etc...

heard! although if the author leaves a response in each thread after pushing each new version, it’ll automatically be tagged with the right version

Ah yes that would be perfect 🙂