Hi, We've recently started trialling Graphite and have been enjoying the stacking workflow overall. One thing we've noticed occasionally is that gt submit seems to hang indefinitely at the "Validating that this Graphite stack is ready to submit..." step — it just sits there until we kill it and try again. We're not sure if we're missing something in our setup, or if there's a known condition that causes this. Is there anything on our end that could trigger this behaviour? And is there a recommended way to diagnose it when it happens, rather than just quitting and retrying? Thanks

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

• it happens frequently enough to be noticed and be a problem

hey Luca, what

gt --version

are you using?

Let me ask @Gareth Brickman

thanks! As a first pass I recommend updating the CLI to the most recent stable version for fixes and improvements. Then next time

gt submit

is run use the

--debug

flag as well to print the logs to your terminal in real-time. This can show whether an underlying process is really hanging, or if there is just a lot of processing happening once it reaches that step.

Thank you, @Gareth Brickman, it sounds good.

sure

It is basically a back-and-forth conversation between him and me (copy and paste from our Slack) Chris [12:40 PM] These issues came up a lot: 1. Graphite's tracking system is independent of git. So while git stays in sync, graphite doesn't. Which means we get stuck in rebase hell. 2. Sometimes the "validating..." message jsut hangs until I quit the command. 3. Graphite's gt move doesn't ever seem to work for me. Attached is an example. I have this stack of three, where the most recent branch is feature/pla-133. If I try to move the next PR - feature/wfm-46 - onto that stack, I get two "does not need to restack" messages, and then a whole rebase UI. Meanwhile, git knows that each one follows on from the other -- no rebases needed, no mess. AND graphite itself knows that wfm-46 is following on from pla-133 because it shows as much in the stack UI here. 4. Graphite's code reviews are not good enough. They catch the tiniest things, but in my experience copilot and claude catch much more and actually evaluate the intent. Perhaps I need more time with graphite to truly understand its value. I think one of the contributing factors is that I'm trying to get as much done as quickly as possible and I don't have time to learn a new tool. But so far, graphite has been a productivity killer rather than a helper. (edited) Luca [2:30 PM] 1) Yes, the Graphite tracking is independent of git, but by design. The only way to not have this issue is to exclusively use Graphite's CLI. The question here is: Is this possible for us to switch to it quickly? 2) I am asking them directly. I couldn't really find concrete evidence that this is an issue on their side in terms of reliability, but it is worth asking. If this happens again, please try to use

gt feedback

and share it with me. 3) I think your frustration here is understandable, but I think the underlying behaviour is actually correct. There's a difference between Graphite knowing that one branch sits on top of another in the stack, and the actual git history reflecting that. When the branches have genuinely diverged (which ours had, hence the package.json conflict), a real rebase is needed to bring the history in line. That conflict would have existed regardless of whether you used Graphite or plain git. I think the frustration comes from

gt move

not making this very clear, it just drops you into a rebase UI without explaining why. Hopefully I got this right. Chris [2:35 PM] I'm not sure the divergence was as severe as graphite's UI made it seem. There were package json conflicts, true, but graphite wanted to redo the entire commit history. Made it seem like there was a lot more in conflict than there actually was. It was a frustrating experience -- possibly this is where I'd need to spend some time/practice to understand it better. When I switched back to using git I had a striaghtforward merge conflict to handle and then I was done. Luca [2:44 PM] I get you, and it is a very fair point, I think the conflict was probably minor but Graphite's rebase approach can make it feel much bigger than it is. It feels almost a merge vs rebase trade-off I am not entirely sure, it just feels that way, and most likely you are right in saying that we need to practice and understand it better 4) I think this is fair, and I agree. Where I see the value here is the dashboard. I found it very useful and definitely worth it.

hey Luca, don't have anything substantive to add to your responses there

OK, thank you for helping @Gareth Brickman