This message was deleted.

I’ve tried do this a few times. That does look expected and the option you want is rebase your changes here so that you don’t lose anything you have locally that you haven’t pushed/submitted yet. My top recommendation is to be in close communication with the people your collaborating with on the stack. The merge conflicts can get really complicated really fast if you’re not careful. I’ve had the most success with, as part of code review, I

ds get

their branch, let them know I’m working a change and coordinate it with a time I know they aren’t working on the branch actively, then push my commit, then they can pull it down with overwrite because they know they don’t have any local changes to worry about. But that’s a rare set of circumstances. I’ve actually been having better luck with making a new PR, aka a new diff, with my changes and letting them merge it in through Github UI. I’ll do this for multi-file code change suggestions. Then they can merge it when their ready, or if there are weird conflicts because they already fixed some of the things, they can just cherry pick the parts they want then close the PR without merging it

cc @Jacob Gold stack collaboration

This is expected — we consider versions of a branch to be separate from Git history due to rebasing, so we always prompt to give you full control over what you want your local branch to look like. ++ to Alejandro's take on this

Alejadro's take works, but does require collaboration/coordination. Would be nice to work on your branch without having to care what coworkers are doing. One thing that works is a

git rebase --onto

flow, where you rebase your local commits onto the remote, effectively bypassing the merge conflicts of prior work on the branch. Example: stack with branches

a, b

branch

a

, commits

a1, a2

branch

b

, commits

b1, b2

coworker adds

a3

, restacks

b

, results in stack

a1, a2, a3, b1', b2'

(accent's indicate rebased commits) coworker submits in parrallel, I add

b3

, results in local stack

a1, a2, b1, b2, b3

I want to submit, but get the gt conflict, I can

rebase

or

overwrite

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'

If

b2

changes lines that were changed in

b1

, this already results in conflicts that I am prompted to "solve" in the interactive rebase ...because the first rebase step is basically

b1

onto

b2'

One way to solve this is:

git fetch && git rebase --onto origin/b b2

This ignores my local commits

b1, b2

and just adds

b3

on top of

b2'

Now I wonder if it would be possible for graphite to abstract over this

git rebase --onto

flow and do it automagically 🪄