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

Merge strategy rebase or merge #31

Closed
oklas opened this issue Oct 11, 2021 · 1 comment
Closed

Merge strategy rebase or merge #31

oklas opened this issue Oct 11, 2021 · 1 comment
Labels
discussion 🗨️ Discussion about a particular topic. wontdo 😕 We will not be doing this at this time

Comments

@oklas
Copy link
Contributor

oklas commented Oct 11, 2021

To minimize and simplify discussion of code quality #5, let us discuss merge strategy here

The result slice of code will be the same. The question is only about git history and how to work with it. This is part of history of this project where merge approach is used:

This requires more attention at navigate through - merge commits has more than one parents.

There are at least two commit in history which has different features and does not include both.

Search commit that has an error become more complicated, it may appear and disappear in linear order (for example image above commit 558 appears at af6 and ff0 but not appears between them at b4d). Fortunately git has a tool to simplify search.

By the way GitHub hides this branches from user, in opposite bitbucket shows them.

If we try to take a look to merge commit it is empty in most cases but may contain conflict resolution or some else (what? the question for discuss also). Empty merge commit is correct due to changes actually present in parent branches but little confusing and involve to navigate to other commits in parent branches.

From the other side branches shows how works moves and they represent itself some sort of formatting or division for fragments the works.

This the part of linear history identical rebase approach (taken also from this project):

image

However top commits a285 and 88a6 may be was made by merge strategy but actually has one parent commit (but actually created by rebase or just empty generic commits), and they are empty. It is possible to create empty generic single parent commit also. But what is the reason and how that commits actually created it is not clean for now. But the topic is not about that coimmis but about merge strategy.

That is the thought I would like to share in addition to what may be found in web.

@HappyZombies HappyZombies added discussion 🗨️ Discussion about a particular topic. code quality 🧽 Relating to code quality labels Oct 11, 2021
@oklas oklas mentioned this issue Oct 11, 2021
@HappyZombies HappyZombies removed the code quality 🧽 Relating to code quality label Oct 11, 2021
@HappyZombies
Copy link
Member

So is the goal really for rebase over merging is that it's easier to read later on if we need to look back? I don't see how that's a real pro and switching over from merging to rebase.

We can do a lot of cleanup of the branches by deleting the branch no? I guess I am failing to see the real benefit of rebasing over merging.

@jankapunkt you have any input on this?

@HappyZombies HappyZombies added the awaiting more info 💭 More information is needed label Oct 15, 2021
@HappyZombies HappyZombies added wontdo 😕 We will not be doing this at this time and removed awaiting more info 💭 More information is needed labels Nov 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 🗨️ Discussion about a particular topic. wontdo 😕 We will not be doing this at this time
Projects
None yet
Development

No branches or pull requests

2 participants