zlacker

[parent] [thread] 2 comments
1. Fang_+(OP)[view] [source] 2025-12-05 13:54:30
Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.

Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.

replies(1): >>happyt+85
2. happyt+85[view] [source] 2025-12-05 14:20:17
>>Fang_+(OP)
The use case is that they are not ready to merge yet.
replies(1): >>saint_+E22
◧◩
3. saint_+E22[view] [source] [discussion] 2025-12-06 00:16:28
>>happyt+85
They meant merging the other way, i.e. merging the new changes from main into the stacked feature branches.

This is functionally the same as rebasing, except that the new changes show up at the tip of the commit chain rather than the base. And because it doesn't rewrite history you don't need to force-push.

[go to top]