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

Feature Request: Add rebase option for branches #2739

Open
mishraprafful opened this issue Nov 22, 2021 · 7 comments
Open

Feature Request: Add rebase option for branches #2739

mishraprafful opened this issue Nov 22, 2021 · 7 comments

Comments

@mishraprafful
Copy link
Contributor

mishraprafful commented Nov 22, 2021

Merging branches and resolving merge conflicts can be very difficult, It would be awesome if we have a rebase option also available.

Maybe we can choose a default option at the repository level?
This somehow ties to integration with git, but I believe is a good feature on its own.

@mishraprafful mishraprafful changed the title Add rebase option for branches Feature Request: Add rebase option for branches Nov 22, 2021
@lynnro314
Copy link
Contributor

Hi @mishraprafful, first of all thanks!
I have some follow-up questions in order to see I fully understand your suggestion.

  1. What do you mean by "release option"? rebase option maybe? :)
  2. Do you think adding “ours” or “theirs” strategy options to lakeFS merge functionality will help solve the difficulties you encountered? Something like lakectl merge --strategy=theirs

@arielshaqed
Copy link
Contributor

My 2 agoroth: Some people hate rebases, some love them. Git offers both, and the Git* tools also offer them (e.g. GitHub offers rebase-and-merge as a way to pull PRs). People hate rebases because they rewrite commit histories. People (myself included...) love rebases because they rewrite commit histories and allow you to fix things after the fact.
I think we should be unopinionated here and offer rebases. Clearly workarounds exist, and equally clearly they are not as good for the people who want the actual feature.
Also, some of the issues with rebases vanish with lakeFS, because it is not a distributed view.

@mishraprafful
Copy link
Contributor Author

Hi @lynnro314

  1. yes, I think that was a typo from my end, I meant rebase option.
  2. I think that would help us for sure. 👍🏻

Also, thanks for your inputs @arielshaqed I think I completed agree with you.

@nopcoder nopcoder added the new-feature Issues that introduce new feature or capability label Nov 24, 2021
@lynnro314
Copy link
Contributor

@mishraprafful

With rebase we diff each commit with the base branch and effectively rebasing each commit separately, so we'll need to resolve conflicts (if there are any) with every commit.
With that in mind, I would love to hear about your requirements for the rebase feature.
Do you thinks adding strategy options to lakeFS merge functionality will be enough (at this point) to solve the difficulties of resolving conflicts? Or the rebase feature is important regardless of resolving conflicts?

@mishraprafful
Copy link
Contributor Author

@lynnro314 I think adding strategy options with merge works for us. I understand that having rebase adds more complexities in terms of resolving conflicts.

With the rebase, we would preserve all the commits that are added to the branch, and we wish to be able to revert to specific commits on the branches as well without having to keep the branches alive. So with rebase, we would be able to have all the effective versions of data on the main branch itself (i.e without losing individual commits on a branch, which we would if using merge to main)

However, once the rebase feature is rolled out we would use that instead of merge. But for now, having strategy options with merge works 🎉

@lynnro314
Copy link
Contributor

lynnro314 commented Nov 24, 2021

@mishraprafful Thanks for your answers!
With respect to this I opened a new issue regarding the merge strategies.
#2750

@lynnro314 lynnro314 pinned this issue Nov 24, 2021
@lynnro314 lynnro314 unpinned this issue Nov 24, 2021
@arielshaqed arielshaqed added the team/versioning-engine Team versioning engine label Mar 16, 2022
Copy link

github-actions bot commented Nov 1, 2023

This issue is now marked as stale after 90 days of inactivity, and will be closed soon. To keep it, mark it with the "no stale" label.

@github-actions github-actions bot added the stale label Nov 1, 2023
@arielshaqed arielshaqed added the no stale Using this label will prevent items from being marked as stale label Nov 7, 2023
@johnnyaug johnnyaug removed the stale label Nov 8, 2023
@talSofer talSofer mentioned this issue Feb 4, 2024
@github-actions github-actions bot added the stale label Mar 20, 2024
@ozkatz ozkatz added feature priority:unknown and removed new-feature Issues that introduce new feature or capability stale no stale Using this label will prevent items from being marked as stale labels Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants