### Problem to solve When a merge request bypasses the merge train using the "merge immediately without restarting pipelines" feature, the merge train reference begins to diverge from the target branch. This creates issues specifically for projects using fast-forward or semi-linear merge strategies: When an immediate non-interrupting merge occurs to a project with a long-running merge train, the train ref starts to diverge from the target branch. This causes two distinct problems: 1. When using fast-forward and semi-linear merge trains, the train ref can no longer be fast-forward merged into the target branch 2. A long running merge train can permanently diverge from the target branch, accumulating changes that make the merge train pipelines non-representative of what would run on the target branch. **Current state:** This issue prevents the "merge immediately" feature from being compatible with fast-forward and semi-linear merge train strategies. **Alternative consideration:** Before implementing this fix, we should evaluate whether merge train partitioning (allowing separate trains per path glob, e.g., `docs/**`, `backend/**`, `frontend/**`) would better serve the underlying use cases while maintaining pipeline integrity. ### Technical Proposal We need to add rebases in two places: 1. When adding a car to a train, if the predecessor is a skip-merge, then use `previous_ref = rebase(previous_non_skip_merge.train_ref, target_ref)` (pseudocode) when creating the train ref for the new car. 2. When merging a car in a fast-forward or semi-linear train, if a skip-merge is detected in the history, rebase the train ref one more time prior to merge. These could be split into two distinct issues.