This message was deleted.
# report-bugs
s
This message was deleted.
k
Copy code
│  │  ◉ 02-18-... (current) 
│  │  │ 15 minutes ago
│  │  │ 
│  │  │ PR #843 ...
│  │  │ <https://app.graphite.dev/github/pr/exponential-hq/isometric/843>
│  │  │ 
│  │  │ c1d6ca5 - ...
│  │  │
│  │  ◯ 02-20-... 
│  │  │ 16 minutes ago
│  │  │ 
│  │  │ PR #853 ...
│  │  │ <https://app.graphite.dev/github/pr/exponential-hq/isometric/853>
│  │  │ 
│  │  │ a9bef2d - ...
│  │  │
│  │  ◯ 02-20-... 
│  │  │ 16 minutes ago
│  │  │ 
│  │  │ PR #852 ...
│  │  │ <https://app.graphite.dev/github/pr/exponential-hq/isometric/852>
│  │  │ 
│  │  │ 7fd156c - ...
│  │  │
│  │  ◯ 02-20-... 
│  │  │ 27 minutes ago
│  │  │ 
│  │  │ PR #854 ...
|  |  | <https://app.graphite.dev/github/pr/exponential-hq/isometric/854>
│  │  │ 
│  │  │ c2774c2 - ...
│  │  │ df08afb - ...
│  │  │
├──┴──┘
◯ main 
│ 2 hours ago
│ 
│ b84eb6f - ...
sorry – I am almost following the one commit per PR convention, with the exception for the bottom PR I would have normally run `gt branch squash`'ed it, but now I'm a bit scared to do it (as something unexpected happened when I tried that a while ago as well) to clarify – the local stack is exactly what I want, it's just that the topmost PR in the stack doesn't look the way it's supposed to on GitHub
i have been restacking the branches quite liberally – there was a bunch of disjoint work that I started to organise into a stack, where the PRs were originally created in an order that has nothing to do with the current order in the stack (as you can see by looking at the numbers)
finally, the 3 bottom PRs are fine in GitHub – they show up as
@kkom
wants to merge 2, 1 & 1 commit(s) into the parent branch (respectively from the bottom)
j
which commit does PR #853's branch point to on github?
k
i don't see any direct evidence for it, but it looks like
7fd156c
(which would be correct) – it has just one (correct) commit in the screenshot I'm attaching and the diff on GH checks out as well same goes for the other 2 PRs
I'm going to have to start merging this stack to continue working, but I'll share some details on how the issue is evolving as I do this
Firstly, Graphite doesn't see any issues when doing `gt stack submit`:
Copy code
(backend-py3.11) ➜  backend git:(02-18-make_calculated_expression_tree_a_list) gt repo sync && gt stack restack && gt stack submit
🌲 Pulling main from remote...
main is up to date.
🧹 Checking if any branches have been merged/closed and can be deleted...
02-20-systematise_expression_variable_names_and_keys does not need to be restacked on main.
02-20-systematise_process_tests does not need to be restacked on 02-20-systematise_expression_variable_names_and_keys.
02-20-add_process-level_tests_to_test_key_uniqueness_and_separation does not need to be restacked on 02-20-systematise_process_tests.
02-18-make_calculated_expression_tree_a_list does not need to be restacked on 02-20-add_process-level_tests_to_test_key_uniqueness_and_separation.
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ 02-20-systematise_expression_variable_names_and_keys (No-op)
▸ 02-20-systematise_process_tests (No-op)
▸ 02-20-add_process-level_tests_to_test_key_uniqueness_and_separation (No-op)
▸ 02-18-make_calculated_expression_tree_a_list (No-op)

🆗 All PRs up to date.
(backend-py3.11) ➜  backend git:(02-18-make_calculated_expression_tree_a_list)
(I won't redact branch names, they aren't that sensitive)
Merged the bottom one into main on GitHub and did this locally:
Copy code
(backend-py3.11) ➜  backend git:(02-18-make_calculated_expression_tree_a_list) gt repo sync && gt stack restack && gt stack submit
🌲 Pulling main from remote...
main fast-forwarded to 09957b5e074dc41b5895ca44dc98cdcb20d695f7.
🧹 Checking if any branches have been merged/closed and can be deleted...
✔ 02-20-systematise_expression_variable_names_and_keys is merged into main. Delete it? … yes
Set parent of 02-20-systematise_process_tests to main.
Deleted branch 02-20-systematise_expression_variable_names_and_keys
Restacked 02-20-systematise_process_tests on main.
Restacked 02-20-add_process-level_tests_to_test_key_uniqueness_and_separation on 02-20-systematise_process_tests.
Restacked 02-18-make_calculated_expression_tree_a_list on 02-20-add_process-level_tests_to_test_key_uniqueness_and_separation.
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ 02-20-systematise_process_tests (Update)
▸ 02-20-add_process-level_tests_to_test_key_uniqueness_and_separation (Update)
▸ 02-18-make_calculated_expression_tree_a_list (Update)

📨 Pushing to remote and creating/updating PRs...
02-20-systematise_process_tests: <https://app.graphite.dev/github/pr/exponential-hq/isometric/852> (updated)
02-20-add_process-level_tests_to_test_key_uniqueness_and_separation: <https://app.graphite.dev/github/pr/exponential-hq/isometric/853> (updated)
02-18-make_calculated_expression_tree_a_list: <https://app.graphite.dev/github/pr/exponential-hq/isometric/843> (updated)
(backend-py3.11) ➜  backend git:(02-18-make_calculated_expression_tree_a_list)
and now the top PR is fine – just 1 commit, instead of 3 of 5 (depending on what you expect would happen after the bottom PR with 2 commits was merged into main)
using
squash merge
strategy on
main
btw (always, it's the only allowed one in our monorepo) and here is the
gt
version:
Copy code
(backend-py3.11) ➜  backend git:(02-18-make_calculated_expression_tree_a_list) gt --version
0.20.14
Ha! This happened to me again – this time to a PR in the middle of a stack. The stack looks like this: • bottom PR (very new, just 1 commit locally and in GitHub) • middle PR (very old – recently upstacked on the bottom one, just 1 commit locally, but incorrectly 2 commits in GitHub – the diff looks wrong) • top PR (very old, has been stacked on top of the middle one for a long time, just 1 commit locally and in GitHub, the diff looks correct)
amending the commit in the middle PR and running
gt stack submit
fixed it - so at least the workaround is clear (and hopefully will be reliable)