Merge branch 'master' of gitlab.com:gitlab-org/gitlab-ce into ce_upstream

doc/development/migration_style_guide.md

@@ -8,6 +8,8 @@ In addition, having to take a server offline for a an upgrade small or big is
 a big burden for most organizations. For this reason it is important that your
 migrations are written carefully, can be applied online and adhere to the style guide below.
 
+It's advised to have offline migrations only in major GitLab releases.
+
 When writing your migrations, also consider that databases might have stale data
 or inconsistencies and guard for that. Try to make as little assumptions as possible
 about the state of the database.
@@ -33,6 +35,8 @@ It is always preferable to have a migration run online. If you expect the migrat
 to take particularly long (for instance, if it loops through all notes),
 this is valuable information to add.
 
+If you don't provide the information it means that a migration is safe to run online.
+
 ### Reversibility
 
 Your migration should be reversible. This is very important, as it should
@@ -85,4 +89,4 @@ select_all("SELECT name, COUNT(id) as cnt FROM tags GROUP BY name HAVING COUNT(i
   execute("UPDATE taggings SET tag_id = #{origin_tag_id} WHERE tag_id IN(#{duplicate_ids.join(",")})")
   execute("DELETE FROM tags WHERE id IN(#{duplicate_ids.join(",")})")
 end
-```
+```
\ No newline at end of file

doc/workflow/gitlab_flow.md

@@ -187,12 +187,15 @@ If you have an issue that spans across multiple repositories, the best thing is
 ![Vim screen showing the rebase view](rebase.png)
 
 With git you can use an interactive rebase (`rebase -i`) to squash multiple commits into one and reorder them.
+In GitLab EE and .com you can also [rebase before merge](http://doc.gitlab.com/ee/workflow/rebase_before_merge.html) from the web interface.
 This functionality is useful if you made a couple of commits for small changes during development and want to replace them with a single commit or if you want to make the order more logical.
 However you should never rebase commits you have pushed to a remote server.
 Somebody can have referred to the commits or cherry-picked them.
 When you rebase you change the identifier (SHA-1) of the commit and this is confusing.
 If you do that the same change will be known under multiple identifiers and this can cause much confusion.
 If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit.
+Another reasons not to rebase is that you lose authorship information, maybe someone created a merge request, another person pushed a commit on there to improve it and a third one merged it.
+In this case rebasing all the commits into one prevent the other authors from being properly attributed and sharing part of the [git blame](https://git-scm.com/docs/git-blame).
 
 People are encouraged to commit often and to frequently push to the remote repository so other people are aware what everyone is working on.
 This will lead to many commits per change which makes the history harder to understand.
@@ -221,13 +224,11 @@ You can reuse recorded resolutions (rerere) sometimes, but without rebasing you
 There has to be a better way to avoid many merge commits.
 
 The way to prevent creating many merge commits is to not frequently merge master into the feature branch.
-We'll discuss the three reasons to merge in master: leveraging code, solving merge conflicts and long running branches.
+We'll discuss the three reasons to merge in master: leveraging code, merge conflicts, and long running branches.
 If you need to leverage some code that was introduced in master after you created the feature branch you can sometimes solve this by just cherry-picking a commit.
 If your feature branch has a merge conflict, creating a merge commit is a normal way of solving this.
-You should aim to prevent merge conflicts where they are likely to occur.
-One example is the CHANGELOG file where each significant change in the codebase is documented under a version header.
-Instead of everyone adding their change at the bottom of the list for the current version it is better to randomly insert it in the current list for that version.
-This it is likely that multiple feature branches that add to the CHANGELOG can be merged before a conflict occurs.
+You can prevent some merge conflicts by using [gitattributes](http://git-scm.com/docs/gitattributes) for files that can be in a random order.
+For example in GitLab our changelog file is specified in .gitattributes as `CHANGELOG merge=union` so that there are fewer merge conflicts in it.
 The last reason for creating merge commits is having long lived branches that you want to keep up to date with the latest state of the project.
 Martin Fowler, in [his article about feature branches](http://martinfowler.com/bliki/FeatureBranch.html) talks about this Continuous Integration (CI).
 At GitLab we are guilty of confusing CI with branch testing. Quoting Martin Fowler: "I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.

lib/gitlab/database.rb

@@ -17,7 +17,7 @@ module Gitlab
     end
 
     def true_value
-      if self.class.postgresql?
+      if Gitlab::Database.postgresql?
         "'t'"
       else
         1
@@ -25,7 +25,7 @@ module Gitlab
     end
 
     def false_value
-      if self.class.postgresql?
+      if Gitlab::Database.postgresql?
         "'f'"
       else
         0
@@ -47,9 +47,5 @@ module Gitlab
         row.first
       end
     end
-
-    def connection
-      self.class.connection
-    end
   end
 end

spec/lib/gitlab/database_spec.rb

 require 'spec_helper'
 
+class MigrationTest
+  include Gitlab::Database
+end
+
 describe Gitlab::Database, lib: true do
   # These are just simple smoke tests to check if the methods work (regardless
   # of what they may return).
@@ -34,4 +38,32 @@ describe Gitlab::Database, lib: true do
       end
     end
   end
+
+  describe '#true_value' do
+    it 'returns correct value for PostgreSQL' do
+      expect(described_class).to receive(:postgresql?).and_return(true)
+
+      expect(MigrationTest.new.true_value).to eq "'t'"
+    end
+
+    it 'returns correct value for MySQL' do
+      expect(described_class).to receive(:postgresql?).and_return(false)
+
+      expect(MigrationTest.new.true_value).to eq 1
+    end
+  end
+
+  describe '#false_value' do
+    it 'returns correct value for PostgreSQL' do
+      expect(described_class).to receive(:postgresql?).and_return(true)
+
+      expect(MigrationTest.new.false_value).to eq "'f'"
+    end
+
+    it 'returns correct value for MySQL' do
+      expect(described_class).to receive(:postgresql?).and_return(false)
+
+      expect(MigrationTest.new.false_value).to eq 0
+    end
+  end
 end