Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(merge-lane)!: change no-snap to avoid fast-forward #9159

Merged
merged 2 commits into from
Aug 30, 2024

Conversation

davidfirst
Copy link
Member

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.

@davidfirst davidfirst merged commit 3ab2db4 into master Aug 30, 2024
11 checks passed
@davidfirst davidfirst deleted the no-snap-no-diverge branch August 30, 2024 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants