This is blatently summarized from here: http://dgmstuart.github.io/blog/2017/04/12/how-to-recover-from-rails-database-schema-conflicts-when-rebasing/
I wanted a more succeinct version available to me.
- Try to manually merge it
== Rules == | |
On Infrastructure | |
----------------- | |
There is one system, not a collection of systems. | |
The desired state of the system should be a known quantity. | |
The "known quantity" must be machine parseable. | |
The actual state of the system must self-correct to the desired state. | |
The only authoritative source for the actual state of the system is the system. | |
The entire system must be deployable using source media and text files. |
This is blatently summarized from here: http://dgmstuart.github.io/blog/2017/04/12/how-to-recover-from-rails-database-schema-conflicts-when-rebasing/
I wanted a more succeinct version available to me.
This document is a condensed version of this page: https://rubydoc.info/gems/yard/file/docs/Tags.md
YARD is compatible with all RDoc sytax. YARD's power comes from its meta-data syntax, "tags".
Full tag list here: https://rubydoc.info/gems/yard/file/docs/Tags.md#Tag_List
This is a condensed version of this page: https://docs.ruby-lang.org/en/2.1.0/RDoc/Markup.html
=== Headers
outputs: <h3 id="label-Headers">Headers</h3>
download chrome .deb file from https://www.google.com/chrome/
sudo dpkg -i /tmp/mozilla_rubydev0/google-chrome-stable_current_amd64.deb
This was tested on a Mac running 10.13.6 High Sierra.
Why? I wanted to be able to stop a system spec mid-run if I was having issues with it.
On the mac host:
Install brew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
git log --merges --first-parent master \ | |
--pretty=format:"%h %<(10,trunc)%aN %C(white)%<(15)%ar%Creset %C(red bold)%<(15)%D%Creset %s" | |
Explaining each argument: | |
--merges: only "merge" commits (more than 1 parent); | |
--first-parent master: only merges applied to master. This removes the entries where someone merged master into their branches; | |
--pretty-format: applies the following formatting: | |
%h: the commit short hash; | |
%<(10,trunc)%aN: author name, truncated at 10 chars; | |
%<(15)%ar: the relative commit time, padded to 15 chars; |
There are certain files created by particular editors, IDEs, operating systems, etc., that do not belong in a repository. But adding system-specific files to the repo's .gitignore
is considered a poor practice. This file should only exclude files and directories that are a part of the package that should not be versioned (such as the node_modules
directory) as well as files that are generated (and regenerated) as artifacts of a build process.
All other files should be in your own global gitignore file. Create a file called .gitignore
in your home directory and add anything you want to ignore. You then need to tell git where your global gitignore file is.
git config --global core.excludesfile ~/.gitignore
git config --global core.excludesfile %USERPROFILE%\.gitignore
If both the upstream and your feature branch have made changes to Gemfile
, you will likely receive merge conflicts on Gemfile.lock
when you rebase your feature branch. Don't try to resolve these manually; you'll probably just screw it up. Instead do this:
git checkout --ours Gemfile.lock
bundle
git add Gemfile.lock
git rebase --continue
This ensures that you get a correct Gemfile.lock at each step along the way.
/* This file goes in ~/Library/KeyBindings */ | |
{ | |
/* Remap Home / End keys */ | |
/* Home Button*/ | |
"\UF729" = "moveToBeginningOfLine:"; | |
/* End Button */ | |
"\UF72B" = "moveToEndOfLine:"; | |
/* Shift + Home Button */ | |
"$\UF729" = "moveToBeginningOfLineAndModifySelection:"; | |
/* Shift + End Button */ |