Lot of branches, therefore much disorder. To solve this we can tag and archive.
To keep the git repo tidy we usually recommend to avoid leaving open branches that have already been merged to the main branch.
How to tag a branch and then close correctly on local and remote repos..
1 - Create the tag (locally)
git tag archive/<branchname> <branchname>
2 - push the new tag to remote
git push --tags
3 - delete branch locally
git branch -d <branchname>
4 - delete branch on remote repo
git push origin --delete <branch_name>5 - go to master branch (or other branch) git checkout master
How to recover older tagged branch
1 - go to tag
git checkout archive/<branchname>
2 - recreate branch
git checkout -b new_branch_name
We make rpm packages for most of our libraries and applications, and that brings a lot of benefits. However, when you have too many packages you might (and probably will) forget which package installs a specific file.
$ rpm -qf filename
[root@videus ~]# rpm -qf /bin/bash
Then the file /bin/bash is installed by the package bash-3.0-31
This is pretty straightforward and easy to remember
One common issue while debugging, refactoring or just programming is when you are searching a word or sentence in a huge number of files and folders.
Several algorithms could be implemented but they always will reach a slow or quick reading of files. One by one until they found a match.
Fortunately GNU provide a powerful tool called ‘grep’. Basically filters the file lines searching a specific word. It uses an algorithm optimized to read files, some say that the real secret it is not to read at all.
This example will show you the matches in the file <filename>.
$ grep "foo" <filename>
Now we go a step ahead by adding some parameters to the ‘grep’ command in order to search in all the files and folders in our location. $ grep -nHr
Finally this example will show you a list of lines with the file name followed by a number of line and the corresponding line with the match.
$ grep -nHr "frequency"
test/mpeg-freq-test.c:49: struct v4l2_frequency vf;
test/mpeg-freq-test.c:55: vf.frequency = f[cnt % 2] * 16;
test/mpeg-freq-test.c:59: perror("could not set frequency");
doc/README.radio:26: -f Tune to a specific frequency
Logs are usefull for debugging and tracing what your code is doing, and what has done in the past.
I started using ‘tac’ when reading logs, specially when I need to see what happened recently. $ tac that_log.log | less
From man tac: tac - concatenate and print files in reverse
So with ‘tac’ you get the last line first. Which is nice if you don’t need to see lines from long ago.
After using tac for a while, I feel it is better to read from end to beginning, you read the error first and then what happened before. I think reading the error first makes you be more alert to read the following lines paying more attention.
If just using less to read the last line, you has to press Shift-g and wait a moment to get the last line, and sometimes with large files less hangs for a while.
Another option is to use tail -n<lines> to get the last lines right away, but usually <lines> are not enough.
This is 3 Way Solutions’s official blog focused on technology issues and geeky stuff. In here you will get to know about us in the Research and Development department, our perspectives, challenges, issues, and how we tackle them (or not). Most of our posts will be regarding TV (both analog and digital), Linux, Programming, HPC, etc and how we merge all this to create our products.
3 Way Solutions is a company that sells products and solutions (mostly hardware), but the essence of these products is the software, so the R&D dept is composed mainly of programmers. All of our systems are based on GNU/Linux, and some of our main programming languages are C, C++, Perl, Bash scripts, and more. Our products are intended mainly for broadcast, cable, professional video, and goverment focused on TV Recording, Content detection, Media Monitoring, Content Repurpouse, compliance, QoS and QoE monitoring.
All of our blog entries will be authored by our developers and we will try to keep them in English (we are based in Argentina, so our first language is Spanish, sorry in advance for our English n.nb). We will share, of course without giving our top secrets, tips, tricks, sample scripts and apps, different approaches, and issues we face, hoping to enrich the community and looking for fellow developers perspectives and opinions. Thank you for reading and we hope you like and participate in our posts.