If you read plenty of personal development literature, you always here the concept of Personal Responsibility.
But what does it REALLY MEAN and how do you practice this???
Here’s one way to ACTUALLY PRACTICE Personal Responsibility:
Don’t focus on resources, focus on resourcefulness
Can’t remember and too lazy to look up
If you focus on recourses, you’re likely to focus on what you DON’T HAVE. Essentially deferring the solution-seeking.
If you focus on resourcefulness, you’re looking at what you DO HAVE and making the most of that. And exercising your free agency.
This takes creativity and a little bit of courage.
Keep in mind though, that
Wisdom is the timely application of knowledge
Sometimes you DO need more resources; and sometimes resourcefulness is not enough.
But don’t ASSUME you always need more resources before you’ve had an honest look at yourself first.
Sometimes, just sometimes: Good enough is good enough.
Merge conflicts can show up when you do a ‘git-merge’ or a ‘git-rebase’:
One way you can “anticipate” a git merge is with the ‘diff’ command
Here’s some bash pseudo code using command substitution:
diff -y <(git show branchA:file.txt) <(git show branchB:file.txt)
Remember though ☝️
A diff will always yield results, that’s what a patch is..
The key is when the SAME LINES are being changed: That’s the conflict! 😉
If the lines from diff don’t overlap…you can probably assume the merge or rebase won’t produce a conflict
(at least, for the file you looked at😊)
Here I break down how to read and set Linux permissions in numeric and symbolic mode: ⬇️
I wrote a script to automate the creation of two divergent git branches…’main’ and ‘feature’.
When I rebased ‘feature’ onto ‘main’..no worked was “saved”.
The following code:
git checkout feature
git rebase main -i
even show ‘noop’ in the text editor.
Turns out, my code was creating duplicate patches on each divergent branch (here’s how to reproduce it if your interested, github link)
So when I rebased, git skips “already introduced patches”.
My reaction after 2 hours of reaching this finding:
Here’s how I visualize a Git *Fast Forward* Merge:
Part 2 takes what was introduced in Part 1 and expands upon it.
I’ll show you how to create your own crontab file and some advanced syntax.
This simple and effective introduction to VIM will help you see the big picture and avoid a lot of the common snags people new to VIM get caught by.