This message was deleted.

gt fold

will merge the PR btw, so you don't need to do that manually on github like described

thank you for your response! I just tested it...it seems to kind of work, kind of not. I made two clones of our repo, to simulate collaboration. clone1: I made

main < A < B < C

, then

gt ss

. everything worked as you'd expect clone2:

gt get C

, everything worked as you'd expect (I got the stack) now, in clone 2,

gt checkout B; gt fold; gt ss

, which did indeed close the remote...but the result was a little puzzling (the first image). so it did show B as closed, but it moved C's parent. that is fine, but now in clone1, I did

gt get C

and the new tree was: main -- A -- B |--- C the second image is what happened when, in clone1, I did

get get 11-29-graphite_testing_--_3

the third image is the result of

gt ls

in clone1. so while in clone2 you see what you'd expect, that is to say

main < A < C

, and

gt log

shows that A has the commits from B layered on it...in clone1, it has gotten into this somewhat weird state. if I make sure in clone1 to checkout B and

gt fold

then it is fine, but that is not ideal for collaboration I perhaps may have done something wrong, or maybe there is a better way to do this? I welcome any advice. perhaps the

gt get X

command should be on a different piece? I am never sure if I should do the branch furthest down the tree, or closest to main (I think furthest down?). my goal is a workflow where any collaborates will get the proper stack layout, as long as they do the "right" sync step to start

This is an interesting flag - thanks for the detailed response! We have some plans to make stack collaboration even better, and curious to know if @Jacob Gold has any advice for you here, otherwise this is definitely something we'll take a look at