feed.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" >

  <title type="html">Open Source C++ developer’s journal</title>
  <!--<subtitle>C++ developer's journal</subtitle>-->
  <updated>2021-11-18T15:00:23+02:00</updated>
  <id>https://ahmadsamir.github.io/feed.xml</id>
  <author><name>Ahmad Samir</name></author>
  <link href="https://ahmadsamir.github.io/feed.xml" rel="self" type="application/atom+xml" />
  <link href="https://ahmadsamir.github.io/" rel="alternate" type="text/html" />


<entry>
<title type="html">The Nouveau driver seems to work</title>
<link href="https://ahmadsamir.github.io/posts/nouveau.html" rel="alternate" type="text/html" title="The Nouveau driver seems to work" />
<id>https://ahmadsamir.github.io/posts/nouveau.html</id>
<updated>2021-11-18T00:00:00+02:00</updated>
<published>2021-11-18T00:00:00+02:00</published>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/nouveau.html">&lt;p&gt;I've had an nvidia graphics card for the past 8 years (and nvidia gtx770), I usually alternate between the nvidia proprietary driver and the nouveau open-source driver, i.e. there is a problem in one, I try the other. But I used the proprietary driver more than the nouveau driver, the latter usually performed worse than it's binary-blob-corporate-jailed driver.&lt;/p&gt;
&lt;p&gt;Recently I found that the latest nvidia proprietary driver will finally get GBM support instead of the EGLStream that it currently has (AFAIK, all the other gfx drivers in Linux use GBM, except for nvidia), but... in typical nvidia fashion, they also decided to drop support for older cards, and my card falls into that group, so again, thank you nvidia! again!&lt;/p&gt;
&lt;p&gt;That irked me, so I decided to try using the nouveau driver again; it looks like one of the reasons it always did badly in my current distro is that I didn't have the libdrm_nouveau2 package installed (it's likely that it was installed by default and then I removed it). Once I installed that it seemed to work much better (&lt;code&gt;glxinfo&lt;/code&gt; is actually a very useful tool).&lt;/p&gt;
&lt;p&gt;But it still felt a bit &amp;quot;slower&amp;quot; than the proprietary driver, I tried tweaking the compositor settings in Plasma (systemsettings -&amp;gt; Display and Monitor -&amp;gt; Compositor), and here is what worked for me:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&amp;quot;Keep Window Thumbnails&amp;quot;: &amp;quot;Never&amp;quot;&lt;/li&gt;
&lt;li&gt;&amp;quot;Tearing Prevention (vsync)&amp;quot;: &amp;quot;Only when cheap&amp;quot;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;for what it's worth, setting the vsync option to &amp;quot;only when cheap&amp;quot; I still don't see any tearing, but it seemed to improve the performance quite a bit.&lt;/p&gt;
&lt;p&gt;It seemed to work, apart from some hard system locks (not too frequent, but still annoying), thankfully it looked like a viable option.&lt;/p&gt;
&lt;p&gt;Then I started wondering if there is a way to change the &amp;quot;performance level&amp;quot;, which is an option in the nvidia-settings GUI tool for the proprietary driver; as far as I understand it changes the clock speeds of the various components in the hardware. The proprietary driver could change those levels dynamically based on the load on the system.&lt;/p&gt;
&lt;p&gt;It turns out, I can actually change the &amp;quot;performance level&amp;quot; with the nouveau driver too (I'll post a link to the sources I found at the end).&lt;/p&gt;
&lt;p&gt;Someone had sent me an email to kindly point out that someone reading my blog posts could try the stuff I post about, which is a fair point; so here is a disclaimer, try the following at your own risk, and after you've done your own research.&lt;/p&gt;
&lt;p&gt;With that out of the way, here we go:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;to check the available clock speed levels of the card I used:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
# cat /sys/kernel/debug/dri/0/pstate
07: core 405 MHz memory 648 MHz
0a: core 405-1032 MHz memory 1620 MHz
0e: core 405-1202 MHz memory 7010 MHz
0f: core 405-1202 MHz memory 7010 MHz AC DC
AC: core 1058 MHz memory 7009 MHz
&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;I tested by changing to the &lt;code&gt;0f&lt;/code&gt; state, and it seemed to work:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
# echo 0f &gt; /sys/kernel/debug/dri/0/pstate
# cat /sys/kernel/debug/dri/0/pstate
07: core 405 MHz memory 648 MHz
0a: core 405-1032 MHz memory 1620 MHz
0e: core 405-1202 MHz memory 7010 MHz
0f: core 405-1202 MHz memory 7010 MHz AC DC *
AC: core 1058 MHz memory 7009 MHz
&lt;/pre&gt;
&lt;p&gt;I tried glmark2 (a benchmarking tool available for Linux), and it gave a score of ~100 before this change and ~1000 afterwards, whatever that score means. And indeed the system seems/feels better.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;To make the change permanent, you need to add this to the kernel cmdline (the kernel command line parameters don't support hex values, so I used &lt;code&gt;15&lt;/code&gt;, which is the decimal equivalent of the hex value &lt;code&gt;0x0f&lt;/code&gt;):&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
nouveau.config=NvClkMode=15
&lt;/pre&gt;
&lt;p&gt;On my distro, I had to edit &lt;code&gt;/etc/default/grub&lt;/code&gt; and add that string to GRUB_CMDLINE_LINUX_DEFAULT:&lt;/p&gt;
&lt;pre&gt;
GRUB_CMDLINE_LINUX_DEFAULT=&quot;nouveau.config=NvClkMode=15&quot;
&lt;/pre&gt;
&lt;p&gt;then as root, I executed &lt;code&gt;grub2-mkconfig&lt;/code&gt; to update the boot entries (check your distro's documentation).&lt;/p&gt;
&lt;p&gt;Now my system is running &amp;quot;well&amp;quot;; sure, there is no dynamic management of the performance levels, but I'd rather crank it up to the top level, than suffer the slowness and performance hit.&lt;/p&gt;
&lt;p&gt;Sources:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;https://nouveau.freedesktop.org/KernelModuleParameters.html&quot;&gt;https://nouveau.freedesktop.org/KernelModuleParameters.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://nouveau.freedesktop.org/FeatureMatrix.html&quot;&gt;https://nouveau.freedesktop.org/FeatureMatrix.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://www.reddit.com/r/linux/comments/k5fa93/found_a_guide_on_how_to_reclock_nvidia_cards_at/&quot;&gt;https://www.reddit.com/r/linux/comments/k5fa93/found_a_guide_on_how_to_reclock_nvidia_cards_at/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">I've had an nvidia graphics card for the past 8 years (and nvidia gtx770), I usually alternate between the nvidia proprietary driver and the nouveau open-source driver, i.e. there is a problem in one, I try the other. But I used the proprietary driver more than the nouveau driver, the latter usually performed worse than it's binary-blob-corporate-jailed driver.</summary>
</entry>

<entry>
<title type="html">ninja Build system, and renamed files</title>
<link href="https://ahmadsamir.github.io/posts/ninja-build-system-tip.html" rel="alternate" type="text/html" title="ninja Build system, and renamed files" />
<published>2021-10-16T00:00:00+02:00</published>
<updated>2021-10-16T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/ninja-build-system-tip</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/ninja-build-system-tip.html">&lt;p&gt;I've been hearing about &lt;code&gt;ninja&lt;/code&gt;, I had looked at it some time in the past, and did some local basic benchmarking (using &lt;code&gt;time&lt;/code&gt;), and didn't find a huge difference in build times, both from scratch and incrementally. I tried ninja again recently and found one feature that sells it pretty well to me, it can show the build progress on one line in the terminal.&lt;/p&gt;
&lt;p&gt;So I switched to &lt;code&gt;ninja&lt;/code&gt; to see how that goes, seems to work OK, but a new tool, new quirks, right? :).&lt;/p&gt;
&lt;p&gt;I happened to be using git interactive rebase, and so was jumping between commits, some files were renamed (with &lt;code&gt;git mv&lt;/code&gt;), that's when ninja failed to build incrementally, clearing the build dir and starting anew, worked fine. But incremental builds are very useful, otherwise the waiting times between the usual &amp;quot;modify code, compile, test, repeat&amp;quot; cycles would be longer, and those waiting times aren't my favourite pastime. The workaround turned out to be simple, &lt;code&gt;touch CMakeLists.txt&lt;/code&gt; file in the top source dir, then run ninja again and it should pick up the changes.&lt;/p&gt;
&lt;p&gt;FWIW, that &lt;code&gt;touch CMakeLists.txt&lt;/code&gt; method works too if say, you built KIO against some other Framework's libfoo.so.n, then libfoo.so.n was updated to .n+1, which would make the incremental build fail (with &lt;code&gt;make&lt;/code&gt; at least, haven't seen that with &lt;code&gt;ninja&lt;/code&gt; (yet?)), touch the file, and it picks up the changes (probably since it will check the build dependencies again).&lt;/p&gt;
&lt;p&gt;Have fun hacking at code.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">I've been hearing about ninja, I had looked at it some time in the past, and did some local basic benchmarking (using time), and didn't find a huge difference in build times, both from scratch and incrementally. I tried ninja again recently and found one feature that sells it pretty well to me, it can show the build progress on one line in the terminal.</summary>
</entry>

<entry>
<title type="html">GCC, Clang[d], LSP client, Kate and variadic macro warnings, a short story</title>
<link href="https://ahmadsamir.github.io/posts/gcc-clang-variadic-macros-warnings.html" rel="alternate" type="text/html" title="GCC, Clang[d], LSP client, Kate and variadic macro warnings, a short story" />
<published>2021-10-08T00:00:00+02:00</published>
<updated>2021-10-08T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/gcc-clang-variadic-macros-warnings</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/gcc-clang-variadic-macros-warnings.html">&lt;p&gt;Kate has had an LSP plugin for sometime now, which uses Clangd. It's a great plugin that brings many code navigation/validation features, akin to those available in Qt Creator and KDevelop.&lt;/p&gt;
&lt;p&gt;So naturally since I got it to work, I've been using it. At some point I found out about the &lt;strong&gt;Diagnostics&lt;/strong&gt; tab in the &lt;strong&gt;LSP Client&lt;/strong&gt; tool view in Kate, which displays useful information; however I also saw that it was plagued by a spam of the following warnings:&lt;/p&gt;
&lt;pre&gt;
[clang] Must specify at least one argument for '...' parameter of variadic macro
[qloggingcategory.h:121] Macro 'qCDebug' defined here
&lt;/pre&gt;
&lt;p&gt;which is really annoying to say the least, as it adds needless noise.&lt;/p&gt;
&lt;p&gt;I just ignored it and moved on; then, by accident, while searching for something in the Extra CMake Module KDE repo I found &lt;a href=&quot;https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/KDECompilerSettings.cmake#L546&quot;&gt;this&lt;/a&gt;:&lt;/p&gt;
&lt;pre&gt;
if(CMAKE_CXX_COMPILER_ID MATCHES &quot;Clang&quot;)
    # -Wgnu-zero-variadic-macro-arguments (part of -pedantic) is triggered by every qCDebug() call and therefore results
    # in a lot of noise. This warning is only notifying us that clang is emulating the GCC behaviour
    # instead of the exact standard wording so we can safely ignore it
    set(CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -Wno-gnu-zero-variadic-macro-arguments&quot;)
endif()
&lt;/pre&gt;
&lt;p&gt;this explains why those warnings are shown. Adding &lt;code&gt;-Wno-gnu-zero-variadic-macro-arguments&lt;/code&gt; to my build flags, I use GCC by default, indeed made those warnings stop. But then GCC started complaining about an unrecognised build flag, which is correct, given that that flag is for Clang.&lt;/p&gt;
&lt;p&gt;I started searching for a way to pass that compilation flag to Clangd without involving GCC, and I found &lt;a href=&quot;https://github.com/clangd/clangd/issues/569#issuecomment-715444829&quot;&gt;this&lt;/a&gt;, which led me to &lt;a href=&quot;https://clangd.llvm.org/config.html&quot;&gt;this&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;So, the solution is to create a &lt;strong&gt;.clangd&lt;/strong&gt; file in your repo's top level directory (I created it in the parent dir to my KDE Frameworks git checkouts, this way it affects all of them as Clangd searches for that file in all the parent directories of the current source file), and put this in it:&lt;/p&gt;
&lt;pre&gt;
CompileFlags:
    Add: [-Wno-gnu-zero-variadic-macro-arguments]
&lt;/pre&gt;
&lt;p&gt;The End.&lt;/p&gt;
&lt;p&gt;Feel free to tell me about any corrections in my posts, you can send me an email, or better still, use a GitHub issue.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">Kate has had an LSP plugin for sometime now, which uses Clangd. It's a great plugin that brings many code navigation/validation features, akin to those available in Qt Creator and KDevelop.</summary>
</entry>

<entry>
<title type="html">Firefox and Hardware Acceleration on Linux</title>
<link href="https://ahmadsamir.github.io/posts/firefox-hw-acceleration.html" rel="alternate" type="text/html" title="Firefox and Hardware Acceleration on Linux" />
<published>2021-09-24T00:00:00+02:00</published>
<updated>2021-09-24T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/firefox-hw-acceleration</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/firefox-hw-acceleration.html">&lt;p&gt;In some Firefox version after 88.0 it looks like they're enabling WebRenderer by default, and it also looks like my hardware (an Nvidia graphics card with the proprietary driver)[1] isn't whitelisted, so what Firefox does is enable &amp;quot;software WebRenderer&amp;quot; instead.&lt;/p&gt;
&lt;p&gt;First things first, I had been trying WebRenderer for some time (more than a couple of month) by force-enabling it, and while it seemed to make things better at first, on the whole the experience was awful, and because WebRenderer, if I understand correctly, uses GPU acceleration, that affected the rest of the desktop, so after a while I disabled WebRenderer (and &amp;quot;Hardware Acceleration&amp;quot; in the preferences tab, and set the processes limit to 2, while I was there), and then things seemed to be better.&lt;/p&gt;
&lt;p&gt;Due to the iffy state Firefox can be in sometimes, I had decided to skip updates for as long as I can, i.e. I update Firefox, then stick with the version I have until an extension I use no longer works, or there is a really compelling new feature in a new version of Firefox (which, sadly, doesn't seem to be as often as it was before the &amp;quot;rapid release&amp;quot; schedule Mozilla had adapted...). So here I was using Firefox 88.0, shut the machine down at night, turned it on in the morning, then when I was opening a link, Firefox started and all the tabs had the &amp;quot;your tab crashed&amp;quot; &amp;quot;reload this tab?&amp;quot; message, clicking that button had no effect.&lt;/p&gt;
&lt;p&gt;So nothing worked, not restoring the previous tabs, disabling all extensions, moving ~/.mozilla and starting anew; a couple of online searches later, still nothing, then I looked at &lt;code&gt;rpm -qa --last | less&lt;/code&gt;, now I think the reason is a glibc update, which broke Firefox, probably it would be fixed by rebuilding Firefox against the new glibc. Not really OpenSuse Tumbleweed's problem because the current version of Firefox in the repos is 92.0...&lt;/p&gt;
&lt;p&gt;The bottom line is, either I build Firefox from source (takes a long time, consuming CPU and memory ...etc) or update update to Firefox 92.0. I opted for the latter; and was greeted with laggy UI/scrolling/interacting with the browser ... lots of fun.&lt;/p&gt;
&lt;p&gt;Another online search later, and I found that &amp;quot;software&amp;quot; WebRenderer is enabled (confirmed by looking at about:support in Firefox) and to &lt;a href=&quot;https://www.reddit.com/r/firefox/comments/pkkdgz/how_to_disable_webrender_again/&quot;&gt;disable it&lt;/a&gt; I needed to set &lt;code&gt;gfx.webrender.force-disabled&lt;/code&gt; to &lt;code&gt;true&lt;/code&gt; in about:preferences.&lt;/p&gt;
&lt;p&gt;[1] While I am here, the whole &amp;quot;you should have bought an AMD graphics card!&amp;quot; argument, that I have seen posted in many places whenever someone says he/she is using Nvidia with the proprietary driver, has never sit well with myself. When I was deciding which card to buy 7-8 years ago, the fglrx driver (which is the proprietary driver for AMD cards) back then was awful, all I heard about it were horror stories of users' complaints. The Nvidia proprietary driver was much better at that time. Some years later AMD decided to open-source their driver and upstream it (not sure) to the Linux Kernel, great, good news for users with AMD cards. But you know what? I can't see the future to know that 5 years after I bought that Nvidia card, AMD will become the better choice. So please, if you don't have a solution to the problem a user with an Nvidia card has, don't throw the &amp;quot;you shouldn't have gotten an Nvidia card&amp;quot; argument in there, saying nothing would be more helpful in that case. And you know what also? AMD being a corporation could at any minute stop supporting the open-source driver, right? I am not a lawyer, but I think if management decides it's not in their company's best interest, they could pull the plug. It's not like this hasn't happened before, Intel did stop developing/working on their gfx open-source driver, to the extent that distros were switching to the default Kernel ModeSetting driver.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">In some Firefox version after 88.0 it looks like they're enabling WebRenderer by default, and it also looks like my hardware (an Nvidia graphics card with the proprietary driver)[1] isn't whitelisted, so what Firefox does is enable &amp;quot;software WebRenderer&amp;quot; instead.</summary>
</entry>

<entry>
<title type="html">Get more out of the window title with Konsole</title>
<link href="https://ahmadsamir.github.io/posts/alternate-git-prompt.html" rel="alternate" type="text/html" title="Get more out of the window title with Konsole" />
<published>2021-09-09T00:00:00+02:00</published>
<updated>2021-09-09T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/alternate-git-prompt</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/alternate-git-prompt.html">&lt;p&gt;If you use git on a regular basis, you should look into using git-prompt; there is a file called git-prompt.sh that is shipped with git, the location in your setup varies depending on the Linux distribution you're using, for example in OpenSuse it's /etc/bash_completion.d/git-prompt.sh. The &lt;a href=&quot;https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh&quot;&gt;file&lt;/a&gt; is of course available in the upstream git repo.&lt;/p&gt;
&lt;p&gt;Following the instructions from the top of that file should give you a very useful addition to the prompt of your shell (the file has instructions for BASH and ZSH). However that is not what this blog post is about; this post is about making the Konsole window title more useful, and by that I mean use the window title to show the current dir path and the info from git-prompt.&lt;/p&gt;
&lt;p&gt;Now, the details, (these instructions are for BASH, but I expect it'll work with other shells with a bit of tweaking?):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Set Konsole to show the title from the shell session on the title bar: &lt;em&gt;Settings -&amp;gt; Configure Konsole -&amp;gt; General -&amp;gt; Show window title on the title bar&lt;/em&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Open &lt;em&gt;~/.bashrc&lt;/em&gt; in your favourite editor and add this:&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
# Adds a '*' and/or a '+' character to the window title to show
# the status of the repo, see git-prompt.sh for the details
export GIT_PS1_SHOWDIRTYSTATE=1
&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Next add this small helper function to set the window title (for what this function does see &lt;a id=&quot;function-0&quot; href=&quot;#function-1&quot;&gt;[1]&lt;/a&gt;):&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
__prompt_set_window_title() {
    printf '\e]2;%s %s\a' &quot;$(__git_ps1 &quot; [ %s ]&quot;)&quot; &quot;${PWD/#$HOME/\~}&quot;;
}
&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Next add the &lt;b&gt;__prompt_set_window_title()&lt;/b&gt; function to the PROMPT_COMMAND (the prompt command in BASH is executed after each command in the shell), by putting this on a new line in &lt;em&gt;.bashrc&lt;/em&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;
PROMPT_COMMAND='history -a; __prompt_set_window_title'
&lt;/pre&gt;
&lt;p&gt;For what &lt;code&gt;history -a&lt;/code&gt; does see &lt;a id=&quot;note-2-0&quot; href=&quot;#note-2-1&quot;&gt;[2]&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Now when you &lt;b&gt;cd&lt;/b&gt; to any dir that has a git repo, the name of the branch will be displayed between the square brackets on the title bar, along with a '*' and/or '+' characters to show the status of the repo.&lt;/p&gt;
&lt;hr style=&quot;margin-top: 100px&quot;/&gt;
&lt;a id=&quot;function-1&quot; href=&quot;#function-0&quot;&gt;[1]&lt;/a&gt; Breaking down &lt;b&gt;__prompt_set_window_title()&lt;/b&gt;:
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;prinft '%s %s' &amp;quot;first arg&amp;quot; &amp;quot;second arg&amp;quot;&lt;/code&gt; printf will replace the first &amp;quot;%s&amp;quot; with &amp;quot;first arg&amp;quot; and the second &amp;quot;%s&amp;quot; with the second arg ...etc&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;\e]2;&lt;/code&gt; starts the escape sequence to set the window title and &lt;code&gt;\a&lt;/code&gt; marks the end of it&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;$(__git_ps1 &amp;quot; [ %s ]&amp;quot;)&lt;/code&gt; for this details about this part, read the docs at the beginning of the git-prompt.sh file; this will put the current branch name between square brackets. Note that if you're not in a dir with a git repo, this will show nothing, i.e. an empty string.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;code&gt;${PWD/#$HOME/~}&lt;/code&gt; this will put the path of the current dir (i.e. the string stored in the PWD env var) next to the git branch name (and replace &lt;em&gt;/home/username&lt;/em&gt; with &lt;em&gt;~&lt;/em&gt;), you can remove it if you don't want that behaviour (you'll also want to remove the second &amp;quot;%s&amp;quot; in the &lt;em&gt;printf&lt;/em&gt; command).&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;a id=&quot;note-2-1&quot; href=&quot;#note-2-0&quot;&gt;[2]&lt;/a&gt; &lt;code&gt;history -a&lt;/code&gt; adds a very useful feature, which I picked up from Mandriva more than a decade ago (thanks, Colin Guthrie :)), it appends the shell history to the history file after you run each command, which means that if you open a new terminal emulator window, you'll find that the shell history has the last command you ran from any other shell session; without 'history -a', the shell history is only appended in one go to ~/.bash_history (or whatever it's called in your distro) after you close the session). You can remove the &lt;code&gt;history -a;&lt;/code&gt; part if you don't want that behaviour.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">If you use git on a regular basis, you should look into using git-prompt; there is a file called git-prompt.sh that is shipped with git, the location in your setup varies depending on the Linux distribution you're using, for example in OpenSuse it's /etc/bash_completion.d/git-prompt.sh. The file is of course available in the upstream git repo.</summary>
</entry>

<entry>
<title type="html">When you really appreciate clang-format</title>
<link href="https://ahmadsamir.github.io/posts/old-codebase-clang-format.html" rel="alternate" type="text/html" title="When you really appreciate clang-format" />
<published>2021-09-07T00:00:00+02:00</published>
<updated>2021-09-07T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/old-codebase-clang-format</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/old-codebase-clang-format.html">&lt;p&gt;In the KDE repos, a lot of repositories have been formatted using clang-format (almost all of the KDE Frameworks, and IIRC a lot of parts in Plasma, and some apps, and Okular and KActivities (the latter two have had clang-format much longer before the rest of KDE caught up)).&lt;/p&gt;
&lt;p&gt;There was this Linux Kernel talk given by Greg-Kroah Hartman where he talked about the importance of formatting patches submitted to the Kernel, they have tools/scripts to format patches according to the coding style used in the Kernel, in that talk he said that the human brain recognises patterns, and because of that it is much easier to read code that is formatted in a regular pattern that you're used to; which in, my experience so far, is pretty much true.&lt;/p&gt;
&lt;p&gt;And you can appreciate the code being uniformly formatted in any KDE Frameworks repo; but you have to understand that, to the best of my knowledge, KDE as a community has always had a coding style (especially in the core libraries, formally known as kdelibs, which has been split into separate repos, i.e. went from one monolithic gigantic repo to the &amp;quot;smaller&amp;quot; ones which are the Frameworks nowadays), that was adhered to as much as possible, and any developer in a KDE code review will point out code style issue, so the effect of clang-format there was making something that looked good, look better.&lt;/p&gt;
&lt;p&gt;However to really appreciate what clang-format does, try running it on an old codebase, of a project that had one main developer, so it was his coding style/taste. You run clang-format on something like that (with the set of formatting rules from extra-cmake-module/kde-modules/clang-format.cmake), and suddenly the code is transformed, gone are all the unfamiliar indentation, all the pointy hard tabs, all the braces around if/while/for blocks that aren't on the same line; it's like you put the codebase in the washer, set it to the 10 minutes quick wash program, and then got it out, pristine, smelling of soap. And yes, the human brain recognises patterns, reading that code now is somewhat easier.&lt;/p&gt;
&lt;p&gt;Thanks go to the developers who work on clang-format (and clang in general, apparently they understand that for a tool like that to survive and prosper it must be open-source, with as many developers working on it, paid and volunteers.... remind you of anything?)&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">In the KDE repos, a lot of repositories have been formatted using clang-format (almost all of the KDE Frameworks, and IIRC a lot of parts in Plasma, and some apps, and Okular and KActivities (the latter two have had clang-format much longer before the rest of KDE caught up)).</summary>
</entry>

<entry>
<title type="html">Firefox and virtual desktops</title>
<link href="https://ahmadsamir.github.io/posts/firefox-virtual-desktops.html" rel="alternate" type="text/html" title="Firefox and virtual desktops" />
<published>2021-08-30T00:00:00+02:00</published>
<updated>2021-08-30T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/firefox-virtual-desktops</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/firefox-virtual-desktops.html">&lt;p&gt;At some point Firefox started remebering which window was open on which desktop, which meant that if you're running KDE or GNOME ...etc and open several Firefox windows on different virtual desktops, when you restart Firefox, each window will be restored to the desktop it was open on. Apparently &lt;a href=&quot;https://bugzilla.mozilla.org/show_bug.cgi?id=890125&quot;&gt;that started with Firefox 77&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Which is nice... or not, depending on your use-case; so, the good news is that this is actually configurable via a pref &lt;code&gt;widget.disable-workspace-management&lt;/code&gt; (you can open the config page in Firefox by going to &lt;code&gt;about:config&lt;/code&gt;), that &lt;a href=&quot;https://bugzilla.mozilla.org/show_bug.cgi?id=1628742&quot;&gt;pref was introduced in Firefox 81&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;It took 1-2 restarts to see the changes, but it works.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">At some point Firefox started remebering which window was open on which desktop, which meant that if you're running KDE or GNOME ...etc and open several Firefox windows on different virtual desktops, when you restart Firefox, each window will be restored to the desktop it was open on. Apparently that started with Firefox 77.</summary>
</entry>

<entry>
<title type="html">-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054F00 ?</title>
<link href="https://ahmadsamir.github.io/posts/disable-deprecated-before-and-at.html" rel="alternate" type="text/html" title="-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054F00 ?" />
<published>2021-03-29T00:00:00+02:00</published>
<updated>2021-03-29T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/disable-deprecated-before-and-at</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/disable-deprecated-before-and-at.html">&lt;p&gt;-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054F00&lt;/p&gt;
&lt;pre class=&quot;code&quot;&gt;
        0x054F00
0x05    0x4F   0x00
&lt;/pre&gt;
&lt;p&gt;In terminal:&lt;/p&gt;
&lt;pre class=&quot;code&quot;&gt;
$ printf '%d %d %d\n' 0x05 0x4F 0x00
5 79 0
&lt;/pre&gt;
&lt;p&gt;Using &lt;code&gt;std::cout&lt;/code&gt;:&lt;/p&gt;
&lt;pre class=&quot;code&quot;&gt;
std::cout &lt;&lt; std::dec &lt;&lt; 0x05 &lt;&lt; &quot; &quot;
                      &lt;&lt; 0x4F &lt;&lt; &quot; &quot;
                      &lt;&lt; 0x00 &lt;&lt; std::endl;

Outputs:
5 79 0
&lt;/pre&gt;
&lt;p&gt;And:&lt;/p&gt;
&lt;pre class=&quot;code&quot;&gt;
std::cout &lt;&lt; std::hex &lt;&lt; QT_VERSION_CHECK(5, 79, 0) &lt;&lt;  std::endl;

Outputs:
54f00
&lt;/pre&gt;
&lt;pre class=&quot;code&quot;&gt;
                   54f00
Hexacdecimal: 54    4f   00
Decimal:      5     79   0
&lt;/pre&gt;
&lt;p&gt;I hope you understand now.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;hr /&gt;
&lt;b&gt;Side-note:&lt;/b&gt; I would like to thank Ilya Bizyaev, who took the time to file an issue which resulted in fixing the config files of my blog, so that links created to my blog on https://planet.kde.org actually work.
&lt;p&gt;This is very good because it actually has two results, a) I fixed the config and b) it gave me proof that someone actually read a post from this blog.&lt;/p&gt;
&lt;p&gt;My main goal when I created this blog was to share info, so even if no one reads a new post right after I create one, it could help someone doing an online search some years from now (including myself, since I also think of this blog as my little personal wiki, something like this great all-things-about-BASH wiki https://mywiki.wooledge.org , but much smaller (and not as useful, yet.... ?) :)&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054F00</summary>
</entry>

<entry>
<title type="html">If a workaround “works” for a long time, is it still a workaround?</title>
<link href="https://ahmadsamir.github.io/posts/old-workaround.html" rel="alternate" type="text/html" title="If a workaround “works” for a long time, is it still a workaround?" />
<published>2021-03-20T00:00:00+02:00</published>
<updated>2021-03-20T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/old-workaround</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/old-workaround.html">&lt;p&gt;I remember back during the KDE3 to KDE4 transition, one feature was broken (or removed then brought back? it's been so long I don't recall exactly), and that is, double clicking the window menu button in the title bar (usually that button is the icon of the application to which that window belongs) would close the window. I was accustomed to using that functionality, both when I used Windows and after I switched to Linux, and it was a bit annoying to see that it suddenly didn't work any more...&lt;/p&gt;
&lt;p&gt;So, to workaround that issue, I ended up moving the close button (yes, you can edit those in the KDE desktop (now Plasma) settings, from the &amp;quot;Window Decorations&amp;quot; KCM) from the far right, where it resides by default, to the far left on the title bar. And I've been using that ever since.&lt;/p&gt;
&lt;p&gt;Even when I ran GNOME, I used that desktop for a while, I found that you can edit the buttons on the title bar there too, and I moved the close button the same way.&lt;/p&gt;
&lt;p&gt;So, to answer my own question, if a workaround &lt;i&gt;works&lt;/i&gt; for 10+ years, it ceases to be a workaround and becomes the normal way of doing things (&amp;quot;work&amp;quot; without around?).&lt;/p&gt;
&lt;p&gt;A bonus point, is that I can close a window with one click, instead of having to double click on the window menu button (I think the feature was brought back as an option in the &amp;quot;Window Decorations&amp;quot; KCM, &amp;quot;Close windows by double clicking the menu button&amp;quot;, but I don't need it any more :)).&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">I remember back during the KDE3 to KDE4 transition, one feature was broken (or removed then brought back? it's been so long I don't recall exactly), and that is, double clicking the window menu button in the title bar (usually that button is the icon of the application to which that window belongs) would close the window. I was accustomed to using that functionality, both when I used Windows and after I switched to Linux, and it was a bit annoying to see that it suddenly didn't work any more...</summary>
</entry>


<entry>
<title type="html">NumPad Rebooted</title>
<link href="https://ahmadsamir.github.io/posts/numlock-rebooted.html" rel="alternate" type="text/html" title="NumPad Rebooted" />
<published>2020-10-13T00:00:00+02:00</published>
<updated>2020-10-13T00:00:00+02:00</updated>
<id>https://ahmadsamir.github.io/posts/numlock-rebooted</id>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/numlock-rebooted.html">&lt;p&gt;If you use the PageUp key a lot (e.g. accessing shell history) and instead of hitting PageUp you hit NumLock? and then it happens several times? the solution for me was to remap the NumLock key to become another PageUp.&lt;/p&gt;
&lt;p&gt;This is for systems using Udev (which is now part of systemd), and a USB or PS/2 keyboard; I am not sure this is feasible for laptops, since as far as I know, on a laptop keyboard switching the Numpad on/off can be useful, gives you more keys on the already cramped keyboard.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;First you need to find the &amp;quot;keycode&amp;quot; for the Numlock key; install &lt;code&gt;evtest&lt;/code&gt;, then run it as root from terminal&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Select the device for your keyboard from the list; note down the device number (e.g. /dev/input/event&lt;strong&gt;8&lt;/strong&gt;); this may need a bit of trial and error, usually there are multiple &amp;quot;events&amp;quot; for the same hardware device, e.g. one for handling the regular keyboard keys (A, B, C, Space bar ... etc) and another for handling the multimedia keys on the same keyboard.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Once you select a device, some info about the keyboard hardware will be printed, on my system I see:&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;pre class=&quot;code&quot;&gt;
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0xd62 product 0xd93f version 0x111
Input device name: &quot;      USB Keyboard&quot;
&lt;/pre&gt;
&lt;p&gt;note down the &amp;quot;vendor&amp;quot; (0xd62) and &amp;quot;product&amp;quot; (0xd93f)&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Now, in the terminal, every time you press a key you'll see some info about that key, pressing Numlock I see:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre class=&quot;code&quot;&gt;
Event: time 1602580599.011787, -------------- SYN_REPORT ------------
Event: time 1602580600.611819, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70053
Event: time 1602580600.611819, type 1 (EV_KEY), code 104 (KEY_PAGEUP), value 1
Event: time 1602580600.611819, -------------- SYN_REPORT ------------
Event: time 1602580600.683796, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70053
Event: time 1602580600.683796, type 1 (EV_KEY), code 104 (KEY_PAGEUP), value 0
Event: time 1602580600.683796, -------------- SYN_REPORT ------------
&lt;/pre&gt;
&lt;p&gt;the interesting part in the output is &lt;em&gt;value&lt;/em&gt;, in my case it's &lt;strong&gt;70053&lt;/strong&gt;.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Next create this directory: &lt;code&gt;/etc/udev/hwdb.d/&lt;/code&gt; (/etc/udev/ should already be there). Inside that directory create a text file e.g. &lt;code&gt;foo.hwdb&lt;/code&gt; (the extension has to be &lt;i&gt;.hwdb&lt;/i&gt;), and open it in a text editor&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;The first line in that file, should be something like:&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;code class=&quot;code&quot;&gt;evdev:input:b&lt;em&gt;v0D62pD93F&lt;/em&gt;&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;I constructed that line from the &lt;i&gt;vendor&lt;/i&gt; and &lt;i&gt;product&lt;/i&gt;, respectively (we noted them down earlier). From /usr/lib/udev/hwdb.d/60-keyboard.hwdb:&lt;/p&gt;
&lt;pre&gt;
    #  - Generic input devices match:
    #      evdev:input:bZZZZvYYYYpXXXXeWWWW-VVVV
    #    This matches on the kernel modalias of the input-device, mainly:
    #    ZZZZ is the bus-id (see /usr/include/linux/input.h BUS_*), YYYY, XXXX and
    #    WWWW are the 4-digit hex uppercase vendor, product and version ID and VVVV
    #    is an arbitrary length input-modalias describing the device capabilities.
    #    The vendor, product and version ID for a device node &quot;eventX&quot; is listed
    #    in /sys/class/input/eventX/device/id.
&lt;/pre&gt;
&lt;p&gt;The parts we're interested in are &lt;em&gt;YYYY&lt;/em&gt; and &lt;em&gt;XXXX&lt;/em&gt;, i.e. the &lt;em&gt;vendor&lt;/em&gt; and &lt;em&gt;product&lt;/em&gt;; I set the rest of those hex digits to &amp;quot;*&amp;quot;, since for example, it doesn't matter which bus-id is being used.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The second line:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre class=&quot;code&quot;&gt;
 KEYBOARD_KEY_70053=pageup    # Remap NumLock to PageUp
&lt;/pre&gt; the part after # is a comment
&lt;div class=&quot;note&quot;&gt;&lt;b&gt;Note:&lt;/b&gt; This line starts with one blank space, i.e. it's &quot; KEYBOARD_KEY_70053=pageup&quot;, if you remove that space it won't work, it's iffy about syntax (it was the last time I tried anyway, which was quite a while ago); again see /usr/lib/udev/hwdb.d/60-keyboard.hwdb for examples.
&lt;/div&gt;
&lt;ul&gt;
&lt;li&gt;Save the file, then as root, update the hwdb:&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;code class=&quot;code&quot;&gt;systemd-hwdb update&lt;/code&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;To &amp;quot;apply&amp;quot; the changes, again as root:&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;code class=&quot;code&quot;&gt;udevadm trigger /dev/input/eventX&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;replace &lt;em&gt;X&lt;/em&gt; with the device number you used previously. If this doesn't work, remove/reinsert the usb cable/receiver from the machine.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Now try the Numlock key, pressing it should be the same as pressing PageUp.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;To revert this change, simply remove the &lt;code&gt;foo.hwdb&lt;/code&gt; file and:&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;pre class=&quot;code&quot;&gt;
systemd-hwdb update
udevadm trigger /dev/input/eventX
&lt;/pre&gt;
&lt;p&gt;if the last command above doesn't &amp;quot;apply&amp;quot; the changes remove/reinsert the usb cable/receiver from the machine.&lt;/p&gt;
&lt;hr /&gt;
&lt;p&gt;Of course now you have no way to toggle the Numpad :), so the next logical step is to remap the number keys on the Numpad to always be in number mode i.e. 1 on the Numpad always types 1, 2 on the Numpad always types 2 ...etc, regardless of the state of NumLock. On my system I needed to use:&lt;/p&gt;
&lt;pre&gt;
 KEYBOARD_KEY_70062=0
 KEYBOARD_KEY_70059=1
 KEYBOARD_KEY_7005a=2
 KEYBOARD_KEY_7005b=3
 KEYBOARD_KEY_7005c=4
 KEYBOARD_KEY_7005d=5
 KEYBOARD_KEY_7005e=6
 KEYBOARD_KEY_7005f=7
 KEYBOARD_KEY_70060=8
 KEYBOARD_KEY_70061=9
 KEYBOARD_KEY_70055=asterisk
 KEYBOARD_KEY_70063=dot
 KEYBOARD_KEY_70058=enter
 KEYBOARD_KEY_70056=minus
 KEYBOARD_KEY_70057=plus
 KEYBOARD_KEY_70054=slash
&lt;/pre&gt;
&lt;p&gt;you simply repeat the above steps for each key.&lt;/p&gt;
&lt;p&gt;One other issue that this fixes is booting and then trying to use the Numpad only to find NumLock isn't &amp;quot;on&amp;quot;, this way it's always &amp;quot;on&amp;quot; :)&lt;/p&gt;
&lt;p&gt;I hope this mini-tutorial was useful.&lt;/p&gt;</content>
<author><name>Ahmad Samir</name></author>
<summary type="html">If you use the PageUp key a lot (e.g. accessing shell history) and instead of hitting PageUp you hit NumLock? and then it happens several times? the solution for me was to remap the NumLock key to become another PageUp.</summary>
</entry>

<entry>
<title type="html">Clangd config</title>
<link href="https://ahmadsamir.github.io/posts/12-clangd-config-tweaks.html" rel="alternate" type="text/html" title="Clangd config" />
<id>12-clangd-config-tweaks.html</id>
<updated>2022-08-19T15:00:00+02:00</updated>
<published>2022-08-19T15:00:00+02:00</published>
<author><name>Ahmad Samir</name></author>
<content type="html" xml:base="https://ahmadsamir.github.io/posts/12-clangd-config-tweaks.html">

<h1>Clangd config</h1>

<p class="post-date">2022-08-15</p>

<p>Since <a href="https://kate-editor.org/post/2020/2020-01-01-kate-lsp-client-status/">Kate got LSP support</a> some time ago (thanks to all the developers who made/make this possible, it is a great addition), I've been using it a lot; as you'd expect with any tool, it has some default behaviours that you'd want to disable, and some non-default ones that you want to make use of. Below are some of the config tweaks I've collected over time.</p>

<p>First, there are two ways to change the <a href="https://clangd.llvm.org/config.html">clangd config options</a>:
<ul>
<li>creating a <code>~/.config/clangd/config.yaml</code> text file, which will affect all projects</li>
<li>creating a <code>.clangd</code> in a specific project directory</li>
</ul>
Note that clangd search for a <code>.clangd</code> file in the current dir and then its parent dir ...etc. So, you can have one .clangd file in the parent dir of all your KDE Frameworks checkouts and it'll affect all of them.
</p>

<p>Now the config options:
<ul>
<li>Mark unused includes, this seems to only work with .h headers includes, but not with ForwardingHeaders (e.g. <code>#include &lt;QString&gt;</code> or <code>#include &lt;KIO/Stat&gt;</code>):
<pre>
Diagnostics:
  UnusedIncludes: Strict
</pre>
So while it doesn't work a 100% for KDE code which uses ForwardingHeaders a lot, it is still useful to have, since you can remove some unused includes as you go along. Of course be careful as it could mark something as "unused" while it is actually needed for a different code path, e.g. only needed on FreeBSD or Windows.
</li>

<li>Disable/suppress showing "Diagnostics" for system headers (if you're a developer for system libraries, you'll have those libraries source code open in your editor, right? if I have a KDE Framework code open in my editor, I want to see issues about that code at his moment, not the system headers, please):
<pre>
---

If:
  PathMatch: /usr/include/.*
Diagnostics:
  Suppress: "*"
</pre>
</li>
If I understand correctly, the <em>---</em> is used to separate sections in the config file, so that means I only want to suppress Diagnostics for this PathMatch not everywhere else.

<li>Add/Remove compile flags that are passed to the compiler clangd uses (by default it uses clang, obviously):
<pre>
CompileFlags:
    Add: [-Wno-gnu-zero-variadic-macro-arguments]
    Remove: [-fdiagnostics-urls=always]
</pre>
For example I usually compile with gcc, and I add the <a href="https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Diagnostic-Message-Formatting-Options.html"><code>-fdiagnostics-urls=always</code></a> flag, but clang knows nothing about it and keeps complaining in e.g. the LSP diagnostics tab in Kate, so this is one way of removing that noisy warning.

For <code>-Wno-gnu-zero-variadic-macro-arguments</code> see this <a href="https://ahmadsamir.github.io/posts/gcc-clang-variadic-macros-warnings.html">post</a>.
</li>
</ul>
</p>
</content>
<summary type="html">
Clangd config tweaks
</summary>
</entry>


<entry>
<title type="html">Git</title>
<link href="https://ahmadsamir.github.io/posts/13-git.html" rel="alternate" type="text/html" title="Git" />
<id>13-Git.html</id>
<updated>2022-10-04T15:30:00+02:00</updated>
<published>2022-10-04T15:30:00+02:00</published>
<author><name>Ahmad Samir</name></author>
<content type="xhtml" xml:base="https://ahmadsamir.github.io/posts/13-git.html">

<h1>Git</h1>

<p class="post-date">2022-10-04</p>

<p>Git is one of those tools that I have been using for the past 4-5 years on a daily basis, very very good tool. Below I share some git commands and aliases ...etc, that I've collected over the years.</p>

<p><a href="https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases"><b>Aliases</b>:</a></p>

<ul>
<li><b>l = log</b><br/> how many times do you type <code>git log</code>?</li>

<li><b>logs = log --pickaxe-all -p -S</b><br/>
This is useful when searching in a repo's commit log for a line of code (verbatim), it shows all the commits where a string of text appears; the <code>-p</code> option makes it show the diff along with the commit message, very good for searching in e.g. less (or whatever pager you use); for what <b>--pickaxe-all</b> does, have a look at the <a href="https://git-scm.com/docs/git-log">documentation</a>
</li>

<li><b>logg = log --pickaxe-all -p -G</b><br/>
The same as the previous one but uses "-G" (instead of "-S"), which takes a regular expression</li>

<li><b>rei = rebase --interactive</b></li>
<li><b>rec = rebase --continue</b></li>

<li><b>cot = checkout -t origin/master -b</b><br/>
Creates a new branch, that tracks the remote origin/master branch, and switches to that new branch, for example <code>git cot blahbleh</code>
</li>

<li><b>cotqt = checkout -t origin/dev -b</b><br/>
The same as the previous one but for Qt repos, they use "dev" instead of "master"...
</li>

<li><b>one-long = log --pretty=format:\"%Cblue%H    %&gt;(20,trunc)%Cgreen%an%Creset %Cred%s%Creset\"</b><br/>
Shows git log of a repo, one line per commit:<br/>
<span class="terminal">
<span style="color:#4980ff">fd2a2f2806064e71c4e64c80a361bc4b2ef64bd2 &#160;&#160;&#160;</span><span style="color:#18b218">John Foo &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;</span><span style="color:#b2b2b2">&#160;</span><span style="color:#ff7361">De-duplicate some code</span>
</span><br/>
See the documentation for more info.
</li>

<li><b>lbr = log -p origin/master..</b><br/>
Shows all the commits in the current branch (i.e. ones at the top that aren't in master yet); again "-p" makes it show the diff along with the commit message, remove it if you want to see commit messages only
</li>

<li><b>g =!git gui &amp; disown</b><br/> "&amp; disown", at least with BASH, means send it to the background, and detach it from this terminal, i.e. the GUI app won't be closed when you close the terminal
</li>
</ul>

<p><b>Custom Git Commands:</b></p>

<p>Some other commands are too big for an alias, so it's easier to use a git script, basically create a shell script somewhere in your PATH, make it executable and name it git-<i>command_name</i> (where <i>command_name</i> is the name of the command you want use e.g. git-history, you can then use <code>git history</code> like any other git command).</p>

<ul>
<li>git-history:
<pre>
#!/usr/bin/bash
git reflog "$@" | grep "checkout:" | perl -p -e 's@.+checkout: moving from ([^ ]+).+@$1@' | grep -v master | uniq | head -n 20
</pre>
Prints a list of the branch names that you have checked out / switched to/from, in chronological order; useful when you have many local branches and can't remember the name of one of the recent ones you've been working on. (I omit "master", because I don't have trouble remembering the name of that one).
</li>

<li>git-dadd:
<pre>
#!/usr/bin/bash
git diff --name-only --diff-filter=U | xargs git add
</pre>
When doing an interactive rebase and after resolving conflicts, you have to `git add` the files that had conflicts, this command does exactly that.
</li>

<li>git-copy:
<pre>
#!/usr/bin/bash
newName=$(git branch --show-current)-2
git branch --copy $newName
</pre>
Creates a copy of the current branch, named <i>current-branch-name</i>-2, basically creating a backup copy in case whatever changes I am about to attempt doing don't work out.
</li>
</ul>

</content>
<summary type="xhtml">Git</summary>
</entry>

</feed>