Skip to content

GitLab

  • Menu
    • Projects Groups Snippets
      Help
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • G gitlabhq1
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • gpt
  • large_projects
  • gitlabhq1
  • Issues
  • #8372

Closed
Open
Created 10 years ago by Administrator@rootOwner
  • New issue

  • Report abuse

  • New issue

  • Report abuse

Default target branch when forked should'nt be an archived repo

Closed

Default target branch when forked should'nt be an archived repo

Created by: blackeyedboy

GitLab 7.5.1 36679b57 tests full green.

Steps to reproduce :

  • create a repository
  • fork it
  • archive it (the original one, not the fork)
  • do something on the new fork
  • open a MR
  • BRRRRR : the default target branch points to an archived repo which cannot be committed !

See https://github.com/gitlabhq/gitlabhq/pull/5719 referenced in this suggestion http://feedback.gitlab.com/forums/176466-general/suggestions/5518180-smarter-merge-request-target-repo-and-branch-form

I obviously can understand and admit that, when you fork a repo, "most of the time and for most users" they just fork because they only have read access on the original repo and will open a MR from the fork to the original. So the new MR should by default open from fork to forked, if the assertion ("most of the time and for most users") is really true.

But it is not for us ! We don't care about being "minority" and having to adapt. But having to remember changing manually target branch each time we open a MR on a fork introduces frequent "ooops" (as usual when manual...).

In my opinion, to be enjoyable by everybody (most users and minority), this should be configurable on project settings, just a new line "this project has been forked, choose your default target branch :" and a selector like the "Default branch" one. I'm pleased to comment the existing suggestion right now for this parameter, see http://feedback.gitlab.com/forums/176466-general/suggestions/5890100-ability-to-select-the-default-merge-target-for-pro

Now, here is the issue. To avoid default target branch to the original forked repository, we tried to Archive the original repo. As a read-only, it can't be committed, so we imagined it will disappear from the target branch, but it does not !

Linked issues
...

    Related merge requests

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: Wachiwi

      👍

      By Administrator on 2014-11-22T11:36:11 (imported from GitLab project)

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: cirosantilli

      I recommend that you try to keep future issues more to the point, or put the key part at the beginning: I had to read too much to understand what was the problem. ;)

      By Administrator on 2014-11-22T12:58:42 (imported from GitLab project)

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: blackeyedboy

      Awfully, you are not the first to say me I speak too much ! :) I refactored my words with the issue first.

      By Administrator on 2014-11-22T15:44:47 (imported from GitLab project)

    • Administrator
      Administrator @root · 10 years ago
      Owner

      Created by: Akendo

      It's a problem for me as well.

      By Administrator on 2015-03-10T16:10:45 (imported from GitLab project)

    • You're only seeing other activity in the feed. To add a comment, switch to one of the following options.
    Please register or sign in to reply
    0 Assignees
    Assign to
    Milestone
    No milestone
    None
    None
    Time tracking
    Due date
    None
    None
    0
    Labels
    None
    Assign labels
    • No matching results
    • Manage project labels
    Confidentiality
    Not confidential

    You are going to turn on confidentiality. Only team members with at least Reporter access will be able to see and leave comments on the issue.

    Lock issue
    Unlocked
    participants
    Reference:

    Menu

    Projects Groups Snippets
    Help