- .gitignore_global
- .vimrc
# module list (generated by listmodules.py) | |
# | |
# timestamp='20160226T200954Z' | |
# sys.version='2.7.10 (default, Dec 8 2015, 18:25:23) \n[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]' | |
# sys.platform='linux2' | |
# platform='Linux-4.1.13-19.31.amzn1.x86_64-x86_64-with-glibc2.2.5' | |
# | |
BaseHTTPServer | |
Bastion | |
CDROM |
A curated list of AWS resources to prepare for the AWS Certifications |
#!/bin/bash | |
# latest ubuntu 16.04 ami | |
aws ec2 describe-images --owners "099720109477" --filters Name="root-device-type",Values="ebs" \ | |
Name=architecture,Values=x86_64 Name=name,Values='ubuntu/images/hvm-ssd/ubuntu-xenial-16.04*' \ | |
--query 'sort_by(Images, &CreationDate)[-3:].[ImageId, CreationDate, Name]' --output=text | |
aws ec2 describe-images --owners "099720109477" --filters Name="root-device-type",Values="ebs" \ | |
Name=architecture,Values=x86_64 Name=name,Values='ubuntu/images/hvm-ssd/ubuntu-xenial-16.04*' \ | |
--query 'sort_by(Images, &CreationDate)[-1].ImageId' --output=text |
// delete build history in range and reset build number | |
fullJobName = "full/job/name" | |
start = 1 | |
end = 10 | |
nextBuildNumber = 1 | |
item = Jenkins.instance.getItemByFullName(fullJobName) | |
item.builds.each() { build -> | |
if (build.number >= start && build.number <= end) { |
People
![]() :bowtie: |
😄 :smile: |
😆 :laughing: |
---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |
In your local clone of your forked repository, you can add the original GitHub repository as a "remote". ("Remotes" are like nicknames for the URLs of repositories - origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In terms of commands that might look like:
git remote add upstream https://github.com/whoever/whatever.git
git fetch upstream
Branch A has commits (X,Y) that also need to be in Branch B. The cherry-pick operations should be done in the same chronological order that the commits appear in Branch A.
cherry-pick
does support a range of commits, but if you have merge commits in that range, it gets really complicated
git checkout branch-B
git cherry-pick X
git cherry-pick Y
http://zerodie.github.io/blog/2012/01/19/git-rebase-i/
- start squash
git rebase -i sha1_of_last_unchanged_commit
- pick commits to squash into
pick 033beb4 commit to be merged into