this post was submitted on 06 Oct 2023
13 points (93.3% liked)

KDE

5407 readers
305 users here now

KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.

Plasma 6 Bugs

If you encounter a bug, proceed to https://bugs.kde.org/, check whether it has been reported.

If it hasn't, report it yourself.

PLEASE THINK CAREFULLY BEFORE POSTING HERE.

Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.

founded 1 year ago
MODERATORS
 

Hello! Yesterday I submitted my first merge request to a KDE software! I forked the repo, applied the edits, committed them and pushed to my fork, and then from gitlab created a merge request. after a few hours, the author pushed something into the master, making my merge request 1 commit behind the master. On the merge request details page, I now get this error:

Merge blocked: the source branch must be rebased onto the target branch.  [rebase without pipeline]  [rebase]

If I try to click on [rebase], I get this red error:

Source branch is protected from force push

what should I do to make my merge request "mergeable" again?

top 12 comments
sorted by: hot top controversial new old
[–] Zamundaaa@discuss.tchncs.de 3 points 1 year ago

Presumably, your merge request is about merging your fork master branch into the upstream master branch, right?

In that case, you have two options:

  1. Go into the Gitlab settings of your fork, find the setting where branches are protected and disable the protection for your master branch
  2. (the recommended way, at least for future merge requests) always create a feature branch, never work on master in the first place. You can create a branch from what you have right now on the command line with git checkout -b featurename. Then push that branch and create a new merge request for it
[–] louis_sch@lemmy.kde.social 3 points 1 year ago* (last edited 1 year ago)

Basicly :

  • go to your locale repo
  • git checkout master
  • git pull
  • git checkout 'your feature branch'
  • git rebase master

And then you'll maybe have to resolve merge conflicts

They're a ton of guide showing how to deal with this if you need

Here's a good guide, in the gitlab documentation.

https://docs.gitlab.com/ee/topics/git/git_rebase.html

[–] theHamsta@mastodon.social 2 points 1 year ago

@tubbadu as other said, you should not create a PR from your master branch. You can still change the source of your PR using gitlab web UI (at least I think you can change after the initial creation. You may also temporarily remove the branch protection from the master branch using gitlab web UI in the repo setting to move this specific PR forward

[–] tubbadu@lemmy.kde.social 1 points 1 year ago

Thanks to everyone for the answers!

[–] mokazemi@discuss.tchncs.de 1 points 1 year ago (1 children)

I guess you should rebase or merge the Master branch into your branch and then push again:

git checkout master
git pull origin master
git checkout yourbranch
git rebase master
git push -f origin yourbranch 

But if you got error since that new commit has conflict with your chances:

git merge master
git push origin yourbranch 
[–] glue_snorter@lemmy.sdfeu.org 2 points 1 year ago (2 children)

No! Bad dev! No biscuit!

Never merge master into a feature branch. It's called a "wrong-way" merge and it makes the history fucking awful.

You shit in the face of project maintainers when you do this.

You may not care, in fact many don't. Also people buy timeshares, read celebrity gossip magazines, and vote for scumbags. They are fucking idiots who don't know what they are doing. So are people who leave wrong-way merges in shared history.

In fact, wrong-way mergers are worse, because you can't just ignore them - git blame rubs your face in their shit, so they shit in your face forever.

Just don't fucking do it, OK? Or I will hit you in the throat with a cricket bat soaked in wasps. As a first warning.

[–] bert@sh.itjust.works 2 points 1 year ago

Not an issue if you're squashing commits before merging into master though, right?

[–] mokazemi@discuss.tchncs.de 1 points 1 year ago (1 children)

Sure I promise not to do it anymore. Calm down. Take a deep breath at first! :)) Could you explain the right way to do it? I'm not expert in using git. Explain the correct way to deal with the situation.

[–] Fal@yiffit.net 1 points 1 year ago (1 children)

Your first way was the right way, rebasing

[–] mokazemi@discuss.tchncs.de 1 points 1 year ago (1 children)

Mmm... And what if it had conflict and I got error?

[–] louis_sch@lemmy.kde.social 2 points 1 year ago

Resolve those conflicts !