How to deal with long lived branches

[uloco]

Let's say I have a protected branch migration (where multiple people work on) and a dependant long lived branch epic (that I own), like

+ main
+ migration  
+ epic
  - epic/feature-1
  - epic/feature-2

There are mulitple branches generated along the way like epic/feature-1 and merged into epic, so that when the big feature epic is done it can get merged into migration again. Development on migration keeps happening and occasionally I need to rebase epic onto migration to get the changes into it.

Should I protect epic here?

If I do so, how do I get the changes from migration into epic and rebase all dependant branches onto this also?
I tried rebasing manually but then I also have to rebase all dependant branches manually.

If I don't protect epic, the branches get updated automatically when I git stack --pull, but since merges happen into epic and not in the latest protected branch, git-stack does not understand this and shows the same changes on different stacks. I also accidentally managed to delete already merged stuff into epic (but I don't remember how this happened).
I am really anxious about deleting stuff here that got already merged since we force push all the time.

What would you do in this scenario with long lived branches?

[epage]

To summarize, the main issue here is branches with different rates of rebasing?

I tried rebasing manually but then I also have to rebase all dependant branches manually.

Once you rebase epic manually, shouldn't a git stack --rebase fix up epic/feature-1, etc?

[uloco]

To summarize, the main issue here is branches with different rates of rebasing?

If you protect epic then yes, I guess. And also, that it's basically a branch I can safely rebase because I own it myself.

Once you rebase epic manually, shouldn't a git stack --rebase fix up epic/feature-1, etc?

I think I tried this and it did not work... Do I have to have a specific branch checked out for this to work correctly?

[uloco]

Also does it make any difference whether origin/* is up to date for example? I have it sometimes, that origin and the local branch are split up into multiple entries in git stack but they point to the same commit, which looks weird. But I don't know if this is related to this...

[epage]

I think I tried this and it did not work... Do I have to have a specific branch checked out for this to work correctly?

With the defaults, it shouldn't matter which branch you are on.

Also does it make any difference whether origin/* is up to date for example?

The base should be the local branch. I have played with it being the upstream branch but haven't been fully satisfied with all of the repercussions yet.

[uloco]

I recorded a video to show the behavior what happens after rebasing manually. git stack --rebase does not fix the feature branches. I cut out the actual merge resolutions and boring parts. You can also seeing it splitting it up in multiple branches with the same name and commit... Don't know whats happening tbh.

The branch equivalents here are:

migration		=>	graphql-migration
epic 			=>	1757-message-overview
epic/feature-1		=>	message-subscription

git-stack.manual.rebase.mp4

[epage]

Thanks, that helped clarify a lot!

I had forgotten that you'd run into a difference between the remote and local protected branch. We calculate the base to be the remote version, considering it canonical especially since people sometimes develop on top of the protected branch, whether accidentally or intentionally. It also helps in the implementation for rebasing on top of a remote. Ideally the local commits past the remote wouldn't be protected and so they'd show up, making the situation clear. iirc my rewrite fixes that.

Short term workarounds

• Explicitly specify --base 1757-message-overview --stack descendants (the latter is to make sure development branches off of other protected branches don't get moved)
• First push 1757-message-overview before doing git stack --rebase

Longer term, I'd recommend creating an issue for this case so we can weigh out the different, overlapping use cases to see if there is either a way to naturally support them or to at least help clarify next steps for the user.