Fix missing ending newline in db structure dump:

[ghost]

Fix missing ending newline in db structure dump:

  When dumping database structure with `rake db:structure:dump` and
using migrations, the resulting file will not end with a newline char.
Although it's not mandatory, it breaks a lot of simple use cases with
programs like cat, more, grep, etc.

  This changes use `puts' instead of `<<' to append migration versions
data to the dump.

It would also help if future changes need to append more data in this
dump.

What do you think of it?

[jeremy]

Looks good! Please squash to a single commit.

[ghost]

I did not found how to add the squashed branch here (which is
activerecord-structure_dump-ending_nl-squashed on my github clone),
but here his the squashed commit:

tjouan/rails@a87cd4d47ccff684a410c3bf6e1ee05506458326

[senny]

the Pull Requests on github are reflect the contents of your branch. This means, you can put whatever you want on the branch you created the PR from and it will be updated to reflect that content. For your situation you should be able to push the squashed commit to the branch like so (involves a force push):

git push -f <remote-name-for-your-fork> a87cd4d47ccff684a410c3bf6e1ee05506458326:activerecord-structure_dump-ending_nl

While <remote-name-for-your-fork> is almost certainly "origin". This will push the commit a87cd4d to the branch "activerecord-structure_dump-ending_nl", which is the source of this PR.

[ghost]

Amazing, it worked!

@senny thank you for the detailed clarification. To be honest I must
admit I read that a few hours ago, but couldn't believe it was the
right way to do it as it seems to me that it violates a strong
principle when using DVCS like git: never rewrite a public branch!
So it feels kind of "wrong" to me :-)

However I now kind of understand it plays better with how GitHub
handles pull requests.

As a side note, the hash of the commit changed because I fixed a typo
in the commit message and rebased the change on latest master.

[senny]

never rewrite a public branch!

This is a good principle to follow. I think it's important though to think about what you consider a public branch. The problems start when other people depend on your work. I would consider a branch in your own fork, which is open for discussion to still be a private branch. If someone depends on it, they need a good reason and should be able to fix the situation when your branch changes. I consider PR-Branches to be exposed local branches that you can reason about and you should be able to change them upside down.

[ghost]

Thank you again for more details, I agree it makes sense in the
context of pull requests.