Gitlab related question

Discussion in 'Developers' Forum' started by branov, Apr 26, 2020.

  1. branov

    branov Member

    Hello, I am not familiar with gitlab, so I want to ask for help. I had one waiting merge request in ispconfig git repository. I have another feature / fix to deploy. How can I create a new merge request? I cannot make another fork of the main repository. When I try to push the change to a new branch of my fork and then do merge request it includes also previous which changes already waiting in merge requests.
    I'm kind of lost with correct workflow. Thanks
    ahrasis likes this.
  2. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    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:
    cd /home/branov/ispconfig3/   # wherever your local repo is
    git remote add upstream
    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:
    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:
    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):
    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).
    Last edited: Apr 27, 2020
    ahrasis and till like this.
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
    ahrasis likes this.
  4. branov

    branov Member

    @Jesse Norell thank you for your detailed explanation and workflow. Appreciate that :)
    @till OK, great, I will wait in this situation until your MR approval and in the feature I will do that properly by using branches.

Share This Page