1. 24 Jun, 2016 3 commits
  2. 23 Jun, 2016 9 commits
  3. 22 Jun, 2016 10 commits
    • Robert Speicher's avatar
      Merge branch 'rs-revert-09ab819e' into 'master' · 64a2be3a
      Robert Speicher authored
      Revert "Merge branch '388-option-to-disallow-author-to-approve-merge-request' into 'master'"
      
      This reverts commit 09ab819e, reversing
      changes made to 041f3c27.
      
      This reverts !455 as per https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/479#note_12609455
      
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/18759
      
      See merge request !493
      64a2be3a
    • Robert Speicher's avatar
      Revert "Merge branch '388-option-to-disallow-author-to-approve-merge-request' into 'master' · 8c938b97
      Robert Speicher authored
      This reverts commit 09ab819e, reversing
      changes made to 041f3c27.
      8c938b97
    • Achilleas Pipinellis's avatar
      Merge branch 'doc/geo-89' into 'master' · 642b5485
      Achilleas Pipinellis authored
      Geo documentations improvement for 8.9
      
      Important changes:
      
      * Added note that we don't support MySQL (I don't know if we should add to the limitations or not)
      * Added related files to the TOC
      * Added disaster recovery instructions (we don't support this, but there are manual steps if anyone need)
      * Added troubleshooting instructions
      
      From recent feedback:
      
      We need to improve the SSH keys part of setup instructions, as it's unclear which ssh key you have to add at geo nodes screen and that you have to pre-authorize the connection once (add to known_hosts), so clones can actually work.
      
      Fixes gitlab-org/gitlab-ee#344
      
      See merge request !431
      642b5485
    • Douwe Maan's avatar
      Merge branch '372-approvals-are-lost-after-a-rebase-merge-action-fails' into 'master' · 6a09693d
      Douwe Maan authored
      Don't reset approvals after rebase from UI
      
      Rebasing from the UI should be considered a 'safe' action, so this
      should ignore the 'reset approvals on push' project
      setting.
      
      Unfortunately, as rebase is implemented by working directly on
      a copy of the repository and pushing (as it's not supported fully by
      libgit2), we can't detect this purely with information available to the
      PostReceive job. If we used commit metadata, the MR author could also
      add the same metadata and push without resetting approvals.
      
      To work around this, add a new column to the MergeRequest model to store
      the SHA from the rebase action. (Ensure that this is set before pushing,
      to avoid a race condition!) Then, in PostReceive, don't reset approvals
      if the pushed SHA matches the SHA stored in the database.
      
      ![Approval_reset](/uploads/cc3ae5f417d403b271aa25884af8f54b/Approval_reset.gif)
      
      Closes #372.
      
      @DouweM this was marked as 8.9 but I think it's a bit close to be adding ~"Pick into Stable" - what's the procedure for this? I'm open to changing this implementation; @vsizov and I discussed it this morning and this was the simplest solution we came up with.
      
      See merge request !489
      6a09693d
    • Achilleas Pipinellis's avatar
      de24f3fd
    • Gabriel Mazetto's avatar
      Spelling mistakes · 3443e2fe
      Gabriel Mazetto authored
      3443e2fe
    • Achilleas Pipinellis's avatar
      Merge branch 'mrchrisw/fix-permissions-link' into 'master' · 4ad74185
      Achilleas Pipinellis authored
      Fix link to permissions
      
      
      
      See merge request !495
      4ad74185
    • Sean McGivern's avatar
      Don't reset approvals after rebase from UI · 864870c6
      Sean McGivern authored
      Rebasing from the UI should be considered a 'safe' action, so this
      should ignore the 'reset approvals on push' project
      setting.
      
      Unfortunately, as rebase is implemented by working directly on
      a copy of the repository and pushing (as it's not supported fully by
      libgit2), we can't detect this purely with information available to the
      PostReceive job. If we used commit metadata, the MR author could also
      add the same metadata and push without resetting approvals.
      
      To work around this, add a new column to the MergeRequest model to store
      the SHA from the rebase action. (Ensure that this is set before pushing,
      to avoid a race condition!) Then, in PostReceive, don't reset approvals
      if the pushed SHA matches the SHA stored in the database.
      864870c6
    • Gabriel Mazetto's avatar
    • Chris Wilson's avatar
      Fix link to permissions · 9996fe84
      Chris Wilson authored
      9996fe84
  4. 21 Jun, 2016 18 commits