This message was deleted.
# report-bugss
Slackbot
03/08/2023, 3:29 AMThis message was deleted.
✅ 1
b
Ben Jaffe
03/08/2023, 3:30 AMI’d expect that teal one at the top to be further down the list, either above or below the pink stack. When I have a lot of branches, it’d be great for the older ones to be consistently at the top.
p
Pranathi Peri
03/08/2023, 3:10 PM@Jacob Gold
j
Jacob Gold
03/09/2023, 1:26 AMthe sorting is deterministic, and I believe should be by committer date per list of direct children of a branch, which gets updated on any changes including restack. was 0306 not restacked since the rest of them were?
Jacob Gold
03/09/2023, 1:30 AM⚠️ implementation details ahead (just typing out my own thought stream in case anyone find it interesting 🙂 ):
it might be slightly off that because the sorting happens when we load the git state into memory at the beginning of the command ah typing this out helped me figure out what the bug might be — we don't reload git state into memory at the beginning of each command, only when we perform a disk cache invalidation. so the sorting only corrects itself when you run direct git commands that modify branches.
anyway, i think the fix here is just to do explicit sorting at the actual
gt logJacob Gold
03/09/2023, 1:31 AM(and also so i can paste screenshots of this thread into the linear task lol). anyway, thanks for reporting!
b
Ben Jaffe
03/09/2023, 2:27 AMhaha, I love hearing implementation details
Ben Jaffe
03/09/2023, 2:30 AMAnd I think you might be right. As for your question, I did restack everything, probably at the same time.
Ben Jaffe
03/09/2023, 2:31 AMI just ran
gt rs --force --restackBen Jaffe
03/09/2023, 2:31 AMThanks @Jacob Gold