For left alignment
<img align="left" width="600" height="200" src="https://www.python.org/python-.png">
For right alignment
<img align="right" width="600" height="200" src="https://www.python.org/python-.png">
And for center alignment
# Credits: https://stackoverflow.com/a/74313286/3647782 | |
FROM ubuntu:22.10 as ubuntu-base | |
RUN apt update && apt upgrade -y | |
FROM ubuntu-base as build | |
RUN apt install -y \ | |
wget \ |
#!/bin/bash | |
# Parallel rsync script originally designed for rsyncing | |
# large ata transfers from RAID to RAID for the Aagaard Lab. | |
# Author: Michael Jochum | |
# Location: Baylor College of Medicine, Houston, TX, USA | |
# Contact : [email protected] | |
# Date : 2 November 2020 | |
################################## | |
#Step 0: fill this shit out |
For left alignment
<img align="left" width="600" height="200" src="https://www.python.org/python-.png">
For right alignment
<img align="right" width="600" height="200" src="https://www.python.org/python-.png">
And for center alignment
Setup git send-email: following these instructions I had some problems. But the following worked:
##################### | |
# | |
# Use this with or without the .gitattributes snippet with this Gist | |
# create a fixle.sh file, paste this in and run it. | |
# Why do you want this ? Because Git will see diffs between files shared between Linux and Windows due to differences in line ending handling ( Windows uses CRLF and Unix LF) | |
# This Gist normalizes handling by forcing everything to use Unix style. | |
##################### | |
# Fix Line Endings - Force All Line Endings to LF and Not Windows Default CR or CRLF |
If you are like me you find yourself cloning a repo, making some proposed changes and then deciding to later contributing back using the GitHub Flow convention. Below is a set of instructions I've developed for myself on how to deal with this scenario and an explanation of why it matters based on jagregory's gist.
To follow GitHub flow you should really have created a fork initially as a public representation of the forked repository and the clone that instead. My understanding is that the typical setup would have your local repository pointing to your fork as origin and the original forked repository as upstream so that you can use these keywords in other git commands.
Clone some repo (you've probably already done this step)
git clone [email protected]
javascript: | |
document.querySelectorAll('.load-diff-button').forEach(node => node.click()) |
ssh-keygen | |
-t ed25519 - for greatest security (bits are a fixed size and -b flag will be ignored) | |
-t rsa - for greatest portability (key needs to be greater than 4096 bits) | |
-t ecdsa - faster than RSA or DSA (bits can only be 256, 284, or 521) | |
-t dsa - DEEMED INSECURE - DSA limted to 1024 bit key as specified by FIPS 186-2, No longer allowed by default in OpenSSH 7.0+ | |
-t rsa1 - DEEMED INSECURE - has weaknesses and shouldn't be used (used in protocol 1) | |
-b 4096 bit size | |
-a 500 rounds (should be no smaller than 64, result in slower passphrase verification and increased resistance to brute-force password cracking) | |
-C "[email protected]" comment.. |
#!/bin/sh | |
# inspired by this SO answer by Uwe Geuder | |
# http://stackoverflow.com/questions/277546/can-i-use-git-to-search-for-matching-filenames-in-a-repository/6960138#6960138 | |
# this will create one 'foundin-$rev.txt' file for each of your revisions, feel free to delete them after use | |
# ADJUST THIS TO YOUR NEEDS: | |
SEARCHTERM="file-that-was-long-lost.txt" | |