Gitlab related question

Hello @branov,

Been there, done that. Sometimes merge requests go through quickly, other times they hang around for months, so having been in that exact situation, I like to create a new branch in my own repo for each merge request I work on, then of course you create the merge request against your branch and the correct upstream branch (usually stable-3.1 for now). Then you can work in and do whatever with your own master branch, while your pending merge requests sit there unaffected.

As for now, you could just close your merge request, create a new branch, and create a new merge request against that. If you have many comments and such on the current merge request you may not want to loose those though, and just wait till this MR against (your) master is resolved.

To fix your new feature branch so you can submit another MR, and likewise to keep all future branches clean, make sure they are based upon a commit in the upstream branch (stable-3.1), not based on any commits which you only have in your local repo (unless you want those commits to be part of the MR). You probably have an 'origin' remote right now pointing to your gitlab repo - add one called 'upstream' (or whatever you like) that points to the upstream repo:

Code:

cd /home/branov/ispconfig3/   # wherever your local repo is
git remote add upstream https://git.ispconfig.org/ispconfig/ispconfig3.git

You currently have your new feature branch based on your own master branch, which includes the commits from your other MR. Create a new branch based on upstream/stable-3.1:

Code:

git checkout -b fixing-feature-branch
git fetch upstream
git reset --hard upstream/stable-3.1

Now merge only the commits you want from your existing feature branch into the newer one:

Code:

git checkout fixing-feature-branch
git diff master my-new-feature    #  ensure these are the commits you want in the new branch
git merge master my-new-feature  # merge them if so ... or find/merge the commits you want here

You now have just your new feature in fixing-feature-branch. Make sure it's good/complete, then you can delete the old feature branch based on master, and rename this one; I think you'll have to track the corresponding origin branch afterwards as well (not positive):

Code:

git branch -M fixing-feature-branch new-feature
git branch -t origin new-feature

When you're setup like this, and you notice (in gitlab) one of your merge requests can no longer be merged without conflicts, you can rebase your local feature commits on to upstream/stable-3.1 and fix whatever the conflicts are to keep them current (and hence easier to be reviewed/accepted).

 

The best method indeed is to create a new branch before you start working on a new feature or issue. I'll be merging the requests that are pending for 3.1.16 release this week as I'm working on the Ubuntu 20.04 support at the moment, so the easiest way is probably to wait a few days until your current request is merged.