This message was deleted.

100% - comment permalinks exist and @kush is planning to add a way to copy the link to each comment soon. We’re also working on a better solution for rendering in-line comments that get lost due to rebasing in the right place in Graphite that will make this problem go away entirely!

That’s great to hear! For your second point, just as a reference, sometimes I get caught up in merge conflicts after an interior-edge in the gt stack chain gets merged down. In the rebasing the upstack commits don’t seem to be cherry-picked so they all get renamed. It seems like if the upstack branch got reset to the new downstack parent and the new commits on the upstack branch were cherry-picked in the original commit order, things would go smoother. I thought that was how rebasing worked, but something about the cascading updates in

gt stack restack

seems to break that down? I do this process manually sometimes because it’s a headache to replay old commits on top of themselves. The alternative is to just merge in the downstack branch but that feels risky and prone to possibly overwriting new changes in the upstack branch.

Commit hashes are never the same if you cherry-pick, except if you pick a committee that is already there and thus nothing is done. The hash of a commit in Git has the parent commits encoded and thus the complete history of that commit up to the initial commit. That's also why force-pushing branches (except for in PRs) is a big no-go, as it involves major work everyone else has to do.

@Jack Kenney Does this match what you are saying? https://graphite-community.slack.com/archives/C02ENKC0A9X/p1682571240136819?thread_ts=1678203599.084219&cid=C02ENKC0A9X

Yeah I think that is it @Edo Rivai. The experience I’m having is your example:

I don’t want to overwrite, because that would erase

b3

I pick rebase, this tries to rebase

b1, b2, b3

on top of

b1', b2'

Maybe the

git rebase --onto

solution is what I’m expecting the restack to be doing behind the scenes

Yep, that's what I expected it to do initially, but I think I now understand better why it's not. With the

rebase --onto

flow, I have to manually define which commits to completely skip, because I understand that

b1, b2

is equivalent to

b1', b2'

, but I guess maybe git/gt cannot really know that. Maybe it can though... Not sure 😅