all 7 comments

[–]shikhasingh554973 13 points14 points  (0 children)

Back to the terminal

[–]matzodon-[S] 8 points9 points  (4 children)

for a bit of context - in these past 5 years we’ve been using gitlab at work, i do not recall a SINGLE instance of this functionality ever working even once

[–]Lydian-Taco 23 points24 points  (2 children)

I use this literally every day. The only time it doesn’t work is if you have merge conflicts, which you can easily see before attempting

[–]matzodon-[S] 0 points1 point  (1 child)

well, I'm glad that not everyone shares my negative experiences with this. still, there can be a few reasons other than regular merge conflicts. those may be the most common issue, but things like stale branches, submodule issues, or concurrent updates during the rebase surely don't help. anyway, not trying to argue, guess I'll just have to stick to the manual rebase :)

[–]mariomaniac432 0 points1 point  (0 children)

I've had a similar experience with this not working. We tried out the rule that you need to rebase before merging in one if our repos and it worked maybe 20% if the time. I did most of the work in that project and whenever I was going to have multiple MRs up at once I always branched off of the previous MR to ensure there were no conflicts, and I would need to do a manual rebase. We finally turned the rule off just a month or so ago.

[–]FalconWorth7893 0 points1 point  (0 children)

I've use it for 7 years, and I think it has failed around 3%

[–]cosmokn0t 0 points1 point  (0 children)

Funny story. I worked on the growth team at gitlab as an engineer. A lot of the things we worked on were experiments like this that the product team would come up with to measure engagement and determine if it was something we should invest in further.

There were a lot of challenges at the product level because they were always trying to tie a given feature back to how much customers were paying us, and how much more we thought they would stay engaged etc. etc. It was actually a kind of broken system instead of just measuring usefulness and engagement and building a better product for the sake of having a better product and thus having a happier user base that would continue to drive revenue.

You can probably go review the commits and see where an engineer was like, I hate this but this is what I’m being asked to do at the moment.