1. 13 Nov, 2014 2 commits
    • Valery Sizov's avatar
      fix after merging conflicts · c7ee816d
      Valery Sizov authored
      c7ee816d
    • Valery Sizov's avatar
      Merge CE master into EE master · 3fcd75a9
      Valery Sizov authored
      Conflicts:
      	Gemfile
      	VERSION
      	app/assets/javascripts/project.js.coffee
      	app/assets/javascripts/users_select.js.coffee
      	app/controllers/projects/services_controller.rb
      	app/models/project.rb
      	app/views/groups/edit.html.haml
      	features/project/service.feature
      	features/steps/project/services.rb
      	spec/models/concerns/mentionable_spec.rb
      3fcd75a9
  2. 12 Nov, 2014 17 commits
  3. 11 Nov, 2014 18 commits
  4. 10 Nov, 2014 3 commits
    • Patricio Cano's avatar
      1a900b22
    • Dmitriy Zaporozhets's avatar
      Merge branch 'remove_unused_javascript' into 'master' · 72922cfa
      Dmitriy Zaporozhets authored
      Remove unused javascript
      
      projects:teams:members:index doesn't exists
      
      See merge request !234
      72922cfa
    • Dmitriy Zaporozhets's avatar
      Merge branch 'better-mr-instructions' into 'master' · 5ef19662
      Dmitriy Zaporozhets authored
      Better merge request manual instructions
      
      I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:
      
      1. Alice creates a repository and commits / pushes a single commit with SHA1 `A` to `master`.
      2. Bob forks this repository and creates a new branch `myfeature` on `master` (`A`)
      3. Alice commits `B` to `master` (which has the parent `A`)
      4. Bob creates two commits on `myfeature` `P` and `Q`.
      5. Bob submits the merge request to merge his `myfeature` into Alice's `master` branch.
      6. Alice follows the manual merge request instructions:
        1. `git checkout -b bob/repo-myfeature master`
        2. `git pull http://... myfeature`
      
      The branch `bob/repo-myfeature` was created from Alice's current `master`, which was `B`. When the `pull` is executed, git will fetch Bob's branch and then merged the fetched branch `Q` into the current branch's location `B`. This creates an unnecessary merge commit from `master` into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.
      
      This is even worse if Alice has set `git pull` to rebase by default. In this case, the commit `B` is rebased on top of `Q`. When Alice checks out `master` and merges in the branch, there will actually be a duplicate `B` commit.
      
      These new instructions instead tell the user to fetch Bob's `myfeature` branch. This will fetch the necessary commits `P` and `Q` and create a temporary ref `FETCH_HEAD` pointing to `Q`. Alice will then create her local `bob/repo-myfeature` branch starting at `FETCH_HEAD`. No unnecessary merge commits, and no accidental rebasing.
      
      See merge request !16
      5ef19662