git


How to execute `find` that ignores .git directories

Trying to find a source code file by its content using find and -exec grep, can some times result in getting results from the repository .git folders as well.

This behavior not only does it provide results you do not need but it also makes your search slower.
Below, we propose a couple of solutions on how to make a more efficient search.

Example 1: Ignore all .git folders no matter where they are in the search path

For find to ignore all .git folders, even if they appear on the first level of directories or any in-between until the last one, add -not -path '*/\.git*' to your command as in the example below.
This parameter will instruct find to filter out any file that has anywhere in its path the folder .git. This is very helpful in case a project has dependencies in other projects (repositories) that are part of the internal structure.


find . -type f -not -path '*/\.git/*';

Note, if you are using svn use:


find . -type f -not -path '*/\.svn/*';

Example 2: Ignore all hidden files and folders

To ignore all hidden files and folders from your find results add -not -path '*/\.*' to your command.


find . -not -path '*/\.*';

This parameter instructs find to ignore any file that has anywhere in its path the string /. which is any hidden file or folder in the search path!


How to undo a Git commit that was not pushed

To undo a Git commit that was not pushed, you are given a few major options:

  1. Undo the commit but keep all changes staged
  2. Undo the commit and unstage the changes
  3. Undo the commit and lose all changes

Method 1: Undo commit and keep all files staged

In case you just want to undo the commit and change nothing more, you can use


git reset --soft HEAD~;

This is most often used to make a few changes to your latest commit and/or fix your commit message. Leaves working tree as it was before reset.
soft does not touch the index file or the working tree at all (but resets the head to the previous commit). This leaves all your changed files Changes to be committed, as git status would put it.

Method 2: Undo commit and unstage all files

In case you want to undo the last commit and unstage all the files you can use the following


git reset HEAD~;

or


git reset --mixed HEAD~;

mixed will reset the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

Method 3: Undo the commit and completely remove all changes

The following method will undo the commit and revert all changes so that your state is exactly as it was before you started making changes.


git reset --hard HEAD~;

hard resets the index and working tree. Any changes to tracked files in the working tree since the previous commit are discarded.

 

Note: In case you just want to rewrite the commit message, you could use git –amend instead.


How does ‘git pull’ and ‘git fetch’ differ?

In simple terms, the difference between the two Git commands is that git pull is composed by a git fetch followed by a git merge.

When you use git pull, Git will automatically merge any pulled commits into the branch you are currently working in, without letting you review them first. You will get a prompt only if there is conflict found during automatic merging.

When you use git fetch, Git retrieves any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it will not merge them with your current branch. To integrate the new commits into your current branch, you need to use git merge manually.
This command is particularly useful if you need to keep your repository up to date, but are working on something that might break if you merge your files.
For example, if you will go offline and you need to have those commits available to you but cannot merge at the time, using git fetch you will download the new commits to your machine without affecting your current code. Later you will be able to merge the new commits to your branch as/when you please.


Just some notes for setting up a new OS to develop projects on GNU/Linux Fedora

If the project is in C++ and uses mysql then install

sudo dnf install mysql++-devel;

If the project is in C/C++ and you are missing talloc.h install

sudo dnf install libtalloc-devel;

Set your name and email for all git projects

git config --global --edit
Then fill-in the configuration file similar to below
# This is Git's per-user configuration file.
[user]
# Please adapt and uncomment the following lines:
#       name = Michael, George
#       email = [email protected]
[user]
        name = Michael, George
        email = [email protected]
[gui]
        editor = gedit

or use these individual commands to set the configuration

[[email protected] ~]$ git config --global user.name "Michael, George"
[[email protected] ~]$ git config --global user.email "[email protected]"

Increase amount of inotify watchers

If you are using CLion or IntelliJ IDEA by jetbrains increase the amount of inotify watchers.
CLion, IntelliJ (and other tools of jetbrains) use inotify on GNU/Linux to monitor directories for changes. It’s common to encounter the system limit on the number of files they monitor.

inotify requires a watch handle to be set for each directory in the project. Unfortunately, the default limit of watch handles will not be enough for sized projects, and reaching the limit will force the jetbrains platform to fall back to recursive scans of directory trees.

Create a file (as root) called /etc/sysctl.d/idea.conf and add the following content to it to increase the number of watchers to 512K

fs.inotify.max_user_watches = 524288

Then call sysctl to reload the settings and apply the new configuration

[[email protected] ~]$ sudo sysctl -p --system;
  •  -p[FILE] or --load[=FILE]: Load in sysctl settings from the file  specified  or /etc/sysctl.conf if none  given.
    Specifying - as filename means reading data from standard input. Using this option will mean arguments to sysctl are files, which are read in the order they are specified.
    The file argument may be specified as regular expression.
  •  --system: Load settings from all system configuration files.
     /run/sysctl.d/*.conf
     /etc/sysctl.d/*.conf
     /usr/local/lib/sysctl.d/*.conf
     /usr/lib/sysctl.d/*.conf
     /lib/sysctl.d/*.conf
     /etc/sysctl.conf

git: How to move locally committed (but not pushed) changes to a new branch

Recently, we’ve been working on a certain branch, we did some changes and performed a couple of commits that were not pushed on the remote system.

There was a complication and it was decided that the local changes should not be pushed to the branch that we were working on.
Rather, they changes should go to a new branch which eventually will be merged.

As mentioned above, we already had done some changes and we already had performed the commits.

git status would give us the following:

$ git status;
On branch scanner_pdu_parser_master
Your branch is ahead of 'origin/scanner_pdu_parser_master' by 2 commits.
  (use "git push" to publish your local commits)

So, we needed to change the branch for those local commits.

Solution – Move the local commits to a new branch

First we got the name of the current branch using the command:

git branch;

Then, we switched to a new local branch

git checkout -b banana_peeler;

And, we pushed the local branch to the remote system:

git push --set-upstream origin banana_peeler;

Afterwards, we switched back to the previous branch

git checkout apple_peeler;

And reset it back to its original form, removing our local commits from it:

git reset --hard origin/apple_peeler;

Please note that the last command will delete all changes that are not committed as well.
In other words, any file you modified and did not commit or push, they will be reverted back to the original code as well.


How to use git features on a local project without a Git server

Like many of you, sometimes we develop code that does not belong to a Git server.
Working as so, one would think that we would miss all the features of a Version Control System (VCS).
Fortunately, this assumption is wrong.
Using the already installed Git tools, we can create a new local repository in any system folder with no additional configuration.

To do so, and create a new repository from an existing project, we need to do the following using a terminal/shell:

  1. Navigate into the directory that contains the project e.g. cd /home/bytefreaks/Projects/Party/banana/
  2. Type git init
    This command will create an empty Git repository in that folder and it will produce a message as follows:
    Initialized empty Git repository in /home/bytefreaks/Projects/Party/banana/.git/
  3. In case you have files that should not be included in your repository, it is better that you create a .gitignore file and add them there.
    This way you will be able to indicate all of the files that you don’t want to the repository to track.
  4. Use git add . (please note that you need the dot . for this command)
    This command will stage all files that are not in .gitignore to be part of your next commit.
  5. Finally, type git commit or git commit -m "Initial Commit with status bla bla", to make your first commit to the repository
  6. Profit!

By now, you should have a fully functional local git repository without the assistance of an external server.


About restoring a deleted Git branch

Recently, a branch was deleted from the server without it being merged.
Luckily for us, we had a local copy.

We used used the command git reflog to get access to the reference logs of the branch.
The command returned results similar to the below:

271f0084 HEAD@{0}: pull: Merge made by the 'recursive' strategy.
 0e71c0b HEAD@{1}: commit: Minor change: Cracked NSA systems
 c81624b HEAD@{2}: pull: Fast-forward
 ef1f281 HEAD@{3}: commit (amend): Deployed satelite
 1ed1a5a HEAD@{4}: commit (amend): Deployed satelite
 a8682cb HEAD@{5}: commit (amend): Deployed satelite
 e4560c8 HEAD@{6}: commit (amend): Deployed satelite
 1679a90 HEAD@{7}: commit (amend): Deployed satelite
 d27d2c9 HEAD@{8}: commit: Deployed satelite
 aaf8261 HEAD@{9}: checkout: moving from master to crack-nsa-systems
 2500e11 HEAD@{10}: clone: from ssh:[email protected]:7999/secret/bananas.git

From this information we got the hash value in front of the commit which we wanted to use to restore, which was 271f0084.

Then, we checked out that version using

git checkout 271f0084;

When we tried to push the branch back to the server the Git pre commit hooks blocked the operation.
Based on the rsa key used, we could only submit changes that were committed by the owner of that key.
The option to disable temporarily the pre commit hooks was unfortunately out of the question.
So we had to replace all author names and emails with the name of the one holding the key.

To do so we used the following command before pushing to the server once more:

git filter-branch --commit-filter '
   if [ "$GIT_COMMITTER_NAME" = "Doe, John" ];
   then
     GIT_COMMITTER_NAME="Squarepants, Bob";
     GIT_AUTHOR_NAME="Squarepants, Bob";
     GIT_COMMITTER_EMAIL="[email protected]";
     GIT_AUTHOR_EMAIL="[email protected]";
     git commit-tree "$@";
   else
     git commit-tree "$@";
   fi' HEAD

git filter-branch lets you rewrite Git revision history by rewriting the branches mentioned, in our case it was HEAD, applying custom filters on each revision. Those filters can modify each tree (e.g. removing a file or running a perl rewrite on all files) or information about each commit. Otherwise, all information (including original commit times or merge information) will be preserved.

HEAD is a reference to the currently checked out commit. In normal states, it’s actually a symbolic reference to the branch you have checked out.
Looking at the contents of .git/HEAD you’ll see something similar to ref: refs/heads/master.
The branch itself is a reference to the commit at the tip of the branch.


Git: Create a branch on your local machine, switch to it and then push it on the server

Following are a couple of simple commands that we use daily to create a new branch on git and push it to the git server.

The following command will create locally a new branch called branch_name and switch to it.

git checkout -b branch_name;

The following command will push the local branch you are currently switched to on the git server.
It will be made available to the server using the name branch_name.

git push --set-upstream origin branch_name;