Someone from the product team at Gitlab needs to look at issue 35054

Someone from the product team at Gitlab needs to look at issue 35054(gitlab.com)

29 points by shiv86 5 years ago | 10 comments

k_sze 5 years ago |

I can kinda understand GitLab's reasoning (correct me if I'm wrong): if the conflict resolution needs to happen on the destination branch and the PR author has no permission to directly commit into the destination branch, then there is no way for the PR author to resolve the conflict themselves at all.

Could GitLab adopt a middle-ground approach? Automatically create a new branch where the conflict resolution will happen, so that the feature branch remains untouched, causing fewer unpleasant surprises to the PR author.

shiv86 5 years ago |

It is completely non-intuitive UX which is causing a lot of people issues. Merging branches is the bread and butter of GIT, if you are changing a fundamental primitive (mergers) of how a technology is expected to work, by reversing the direction of the merge request (opposite to the direction provided explicitly by the user) without warning that is a major issue.

wiml 5 years ago | |

It's not really messing with anything fundamental about Git — in fact it's providing a very common workflow for Git users, just in a way that is confusing for people who mainly use Github.

Obviously if lots of people are getting confused something needs to be fixed, but I think this is fundamentally a minor UI wart.

shiv86 5 years ago | | |

> just in a way that is confusing for people who mainly use Github.

As a user I am requesting to merge branch X into branch Y. What Github actually does is merge branch Y into branch W, with insufficient warning to the user. Gitlab users continue to have issues due to this unexpected behavior. I am astounded this problem has not been addressed in a meaningful way, so users dont counter this issue.

dnsmichi 5 years ago |

Thanks for sharing. The issue in question has been closed, and the discussion on changing the behaviour and improving the UX happens in

- Manually resolve conflicts in merge commit on the target branch: https://gitlab.com/gitlab-org/gitlab/-/issues/25014

- Add in application explanation of what Resolve Conflicts is doing: https://gitlab.com/gitlab-org/gitlab/-/issues/25003

I've added that as a comment to https://gitlab.com/gitlab-org/gitlab-foss/-/issues/35054#not...

cghendrix 5 years ago | |

Always so cool when actual devs/stakeholders from mentioned org in the post listen to HN and take action (when appropriate of course)

hardly_a_mirage 5 years ago |

The complete radio silence from Gitlab's team over an issue this serious _over a 3 year period_ compels me to maintain my distance from their product.

cghendrix 5 years ago | |

Yeah they could at least comment on why they are not taking any action.

wdb 5 years ago |

Personally, I think, the merge requests UX in Gitlab ar mediocre compared to GitHub.

The diffs are hard to read because the way render differences. Also it's hard to spot when your merge request has merge conflicts. Could be way more clearly marked.

Also really wish they had similar bot and checks supports like GitHub has.

shepik 5 years ago | |

I've been using gitlab for years, and I think the same about github merge requests - they are extremely hard for me to read. Matter of preference, I guess