Questioning your own understanding is being ‘critical’, not ‘incompetent’.
Use double-dot notation when specifying commit ranges.
git log master..experiment
We are asking the question:
“What range of commits ‘closes the gap’ FROM master TO experiment?” 👇
This will help you with planning git merges.
The output will show you what work (range of commits) you have not merged in yet.
Learning a technical skill in a vacuum (because it’s “cool”) is very dull, boring and won’t sustain you..
But learning a technical skill in pursue of a goal and solving a problem: now things are getting juicy!!!😊
If you’re looking for a Red Hat-based operating system, here are the most popular:
Full Article 👉www.tecmint.com/redhat-based-linux-distributions/
Keep in mind, you can get free self-suppose licenses for Red Hat itself if you want.
Support is still community based but you will be able to stay up-to-date with security and operating system patches.
I can’t let go of my train-of-thought sometimes, but to let go of my art.
- 6 Buddhist Monks
- 5 days and
- 40 hours of painstaking, tedious work
- Symbolizing Impermanence, the nature of life (I guess Olaf was right! )
Anytime you hear the term “Letting go” or “detachment” within spiritual practices and circles…this is probably the most practical, down to earth example of said terms I can think of.
If you’re using a git command but need a quick refresher, remember this syntax:
git <verb> -h
If you need the full man page for a git command, it’s:
git <verb> --help
If you want to see ALL AVAILBLE <verb> options; type git and then TAB key twice (like you would with a linux command):
This post is an iteration of my original post: https://linux-admin.blog/2018/11/01/read-and-troubleshoot-linux-config-files-10x-faster/
In it, I explained how reading and troubleshooting config files in Linux are sometimes a pain in the rear. In particular, when the config files are long and mostly comments.
When we are troubleshooting, we want to know just the effective settings that are going to be loaded at run time and nothing else. And read them quickly.
The script I provided in that original post works, but I’ve iterated it into a more elegant solution.
My solution – then and now – was inspired by a very useful book I discovered years ago: Perl One-Liners: 130 Programs That Get Things Done
So here is my new and improved version; I will also demo the heartburn it removes on two files:
perl -ne 'print unless /^(#|;|\n)/' <filename>
Notice how I defined a comment to be a “#” or a “;”.
Now, if we do a
cat /etc/samba/smb.conf we can see how the output is extremely overwhelming with a lot of comments and blank lines:
egrep -v "^(#|;)" /etc/samba/smb.conf to see the effective settings, but that will still leave ALOT of empty lines:
If we use the Perl Oneliner, we can remove ALL comments, and remove empty lines for EVEN BETTER readability
Now we can quickly see our effective settings in
We can run the same script on
/etc/ssh/sshd_config for easier reading and troubleshooting:
Let take a step back and point out the main benefits with this script.
It will remove all comments (lines beginning with a “#” or “;”) and the empty lines. This will make reading the effective settings quicker and easier.
And make troubleshooting alot easier.
If this code helps you solve any problems, comment and let me know below
Realizing ALL Action Is Imperfect Action
Discovered this free Linux server course recently.
Instructor is Shawn Powers from CBTNuggets and he uses a Centos 7 virtual machine to demonstrate all of the concepts he covers.
Let me know what you think.
When you’re learning Git (or anything for that matter) rapid and cheap testing, feedback, and failure can expedite the learning process from hours to minutes!
When you’re learning and experimenting with Git concepts like:
- The Working directory,
- The Cache (or Index),
- Reading the Commit History,
- Or basically any Git command or concept
You want to have the freedom to make mistakes, even to the point of corrupting the entire Git repository (repo).
Essentially, a “Git Repo Sandbox” that you can rebuild in seconds.
Here is my code to quickly (re)create said “Git Repo Sandbox” that contains:
- 2 Branches (master and dev)
- 1 Merge
Just copy and paste the following code into your bash prompt and let it rip.
There is a merge-conflict warning but it’s ignored because all we want is our “Git Repo Sandbox” up and running again:
rm -Rf ./git_test #<== be VERY careful with this line mkdir ./git_test cd git_test sleep 1 git init echo ":)" >> ./script.sh git add * git commit -m "Commit message" echo ":)" >> ./script.sh git add * git commit -m "Commit message" sleep 1 git branch dev git checkout dev echo ":)" >> ./script.sh git add * git commit -m "Commit message" echo ":)" >> ./script.sh git add * git commit -m "Commit message" sleep 1 git checkout master echo ":)" >> ./script.sh git add * git commit -m "Commit message" sleep 1 git merge dev git add * git commit -m "Commit message" sleep 1 git log --oneline --all --graph --decorate
You will get output similar to the following (only difference is commit hashes):
Here’s a live demo on how to use my code. For me, I performed a Right-click on my mouse to paste:
Now you can study and experiment with as many git concepts and commands to your heart’s content. Or at least, what this simple repository will allow.
You don’t have to worry about making a mistake, because if you corrupt everything, just “re-build and reload”.