feat(merge-lane)!: change no-snap to avoid fast-forward #9159
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, in case lane-b is merged into lane-a and a component (e.g. comp-a) is ahead in lane-b, we simply updated lane-a with the new snap of lane-b. (this behavior is similar to the "fast-forward" in Git).
This was true regardless of
--no-snap
flag. The--no-snap
flag was only for cases when comp-a is diverged in history and no conflicts found, which was auto-snapping the component and saving two parents, the head of lane-a and the head of lane-b.In come cases, the end result of such a merge is not desirable. Some changes might be done to this comp-a in lane-b which I would like to investigate and test before I decide to get them in lane-a. Although comp-a wasn't changed/snapped in my lane-a, still, I prefer to get the changes of comp-a as modified, so then
bit diff
will show the new changes I'm getting and then I can decide later to snap these changes.This PR makes this possible by using the
--no-snap
flag. In practice, it considers this state of target-ahead (lane-b) as diverged, which, as a result - doesn't update lane-a, only the component-files and the unmerged files with the heads data.A new flag
--no-auto-snap
was introduced to keep the previous behavior of--no-snap
in case users need them.