If you're performing a mass database backup using mysqldump, you'll pretty much find it annoying to type in the password every single time.

To get rid of it, open /etc/mysql/my.cnf configuration file and add your database credentials:

[mysqldump]
user="your_username"
password="your_password"

Once done, save the my.cnf configuration file and now, you can try exporting your database without a hassle like this:

mysqldump -u your_username database_name > database.sql

Hope this trick helps you out!

If you're the type of person who types git push -f origin master, please don't do that as it might overwrite your entire branch. I'm saying this because I did this once and I thought I lost all the files.

Luckily, I was a bit relieved as git is a VCS (Version Control Software), which means the files are most likely not deleted. This is when I came across git reflog command.

According to the Git manual, this is what it does:

Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.

This is a life-saver especially if you wanted to return back to the previous point in time. Here's how I recovered my files back again:

1. Type git reflog show remotes/origin/master
2. Find and make note of the previous commit hash.
3. Create a new branch with using the previous commit hash like this: git branch <new_branch_name> <previous_commit_hash>
4. Then finally, push the files to the new branch: git add . && git commit -m "pushing recovered files" && git push origin <new_branch_name>
5. Checkout to the newly created branch: git checkout <new_branch_name>
6. Delete the corrupted branch and replace it with the newly created branch that contains your restored files.

If I didn't discover this, I don't really know what I would have done to recover those files.

References

• Git reflog documentation
• How can I recover from an erronous git push -f origin master?

Hope this helps you out!

This error shows up when two different projects are merged (i.e. they both could be the same project but unaware of each other's existence and have different commit histories).

If you are facing this, chances are that:

1. You must have cloned a project and the .git directory must have corrupted or got deleted and at this point, Git is unaware of the changes being made and will throw this error when you try to push to or pull from the remote repository.

2. You created a new repository, made some changes and added the commits and then you tried to pull from the remote repository.

Well, you can easily resolve by passing the --allow-unrelated-histories flag when pulling the latest updates from the remote repository:

git pull origin master --allow-unrelated-histories

Hope you found this useful!

I wrote a nifty command to make an archive of the files that I have modified on a particular date. By doing so, this script comes in handy during urgent deployments, so that I don't lose track of the files that I should be updating.

Here's the command at your disposal:

find . -maxdepth 10 -type f -newermt "2021-04-10" | zip -qur archive.zip -@

How this works?

Let's see what this command does in pieces:

find is the utility tool used to return the filenames that match the specified parameters in the given directory.

-maxdepth is the flag that allows you to specify the depth of recursive searches it should perform.

-type is the flag that determines if you're looking for file or a directory.

-newermt is the flag that determines if the file has been modified on and/or after the given date.

Once, the file has been found, the output is being redirected to the zip utility function, which would then add the files to the .zip file. The -q flag would perform the operation in silent mode, -u flag would update the files in the archive if modified or add it as a new file if it doesn't exist and -@ takes the list of files from the standard input.

If you want to ignore certain directories or file extensions, in that case, you can exclude them like so:

find . -maxdepth 30 -type f ! -path "./path/to/directory/*" !  -path "*.ext" -newermt "2021-04-10" | zip -qur archive.zip -@

Or, you can even archive the modified files by specifying a date range:

touch --date "2021-04-10" startdate
touch --date "2021-04-15" enddate
find . -maxdepth 30 -type f -newer startdate -not -newer enddate | zip -ur archive.zip -@

Hope you found this tip useful! 😁

If you want to sizes of each directory in a list, try the following command:

du -sh * | sort -h >> directories-sorted.txt

And, if you wanted to find the directory that takes consumes a lot of space in your directory, you can try this:

du -sh * | sort -h | tail -n 1

Hope these tips do come in handy! 😊

Did you make a typo while typing out your Git remote origin URL? Is it pointing towards the wrong repository?

You can easily update it using the following command:

git remote set-url origin https://example.com/username/repository.git

Hope you found this useful!

If you're a developer working in the Middle East, it's quite common that you'll work on a project that bilingual, in our case, it's english and arabic.

In my opinion, it's not aesthetically pleasing and logical to have english numbers in arabic text, so, write a simple helper function to convert the numerals from english to arabic:

<?php
function convertEnglishToArabicNumerals($str) {
    if (\App::getLocale() == 'ar') {
        $westernArabic = array('0', '1', '2', '3', '4', '5', '6', '7', '8', '9');
        $easternArabic = array('٠', '١', '٢', '٣', '٤', '٥', '٦', '٧', '٨', '٩');
        $str = str_replace($westernArabic, $easternArabic, $str);
    }
    return $str;
}
?>

And since most browsers can handle RTL, you don't have to worry about how the arabic numerals are being displayed in your application.

Thought of sharing a simple regular expression that I use on VIM to convert snake_case letters to camelCase letters (see what I did there) 😜

Here's the pattern for you to use:

:s/ \([a-zA-Z]\)/\u\1/g

Hope you found this tip useful!