Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.
Here’s what I learned from starting to read the source code to fff - in particular, the main function.
fffis “a simple file manager written in Bash”. As I’m always on the lookout to learn more about Bash, that description got my attention immediately. It’s a small but perfectly formed offering, complete with man page and even a
Makefilefor installation. And the file manager executable* itself is a single Bash script.
*I use this term deliberately, and it does make me stop and think every time I see scripts in a
bindirectory (where “bin” stands for binary). But that’s a conversation for another time.
The author, Dylan Araps has produced other interesting pieces of software (such as neofetch) as well some great documents such as the pure bash bible as well as the pure sh bible. He’s also the creator of Kiss Linux. He has a reputation for writing great Bash code, so this seems like an opportunity too good to miss to learn from better programmers.
It seems that recently Dylan has disappeared off the radar, I don’t know what the situation is but I wish him well.
Where I can, I link to reference material so you can dig in further to Bash details that take your fancy. This reference material includes the following sites (and there are more of course):
Here is my short answer to that: There isn’t one right way for using Org mode features.
If this is obvious to you, you can skip the rest of this article. If not, you really should read this until the end. It may answer many questions you probably do have in your head. Especially when you’re rather new with the Org mode universe.
Of course, the same rationale is true for all kind of advanced software solutions that offer a certain level of flexibility to its users. However, my examples here are based on Emacs Org mode.
The concept of the staging area is one which many newcomers struggle with when starting to learn git, and the fact that this concept is barely mentioned in the official documentation (i.e. man pages) doesn’t help at all. Instead the official name is “the index” which has absolutely nothing to do with the way users interact with it. That’s the reason most people who teach git prefer to use the term “staging area” instead, and in fact that’s the term used in the best available documentation: the Pro Git book (which is not official), and also pretty much in all online documentation, including tutorials and blog posts (e.g. Atlassian saving changes, code refinery).
Attempts to move away from the incorrect term “the index” towards one that most native and non-native English speakers can grasp without the need for further explanation have been attempted for more than a decade, and even though there’s universal consensus that “staging area” is by far the best alternative, attempts to use it officially in the documentation and user interface have been blocked because one person cannot be convinced.
There’s a keyboard layout I’ve been using for the past 8 or 9 months. It’s called the workgirl layout. It may look familiar to some of you:
By no coincidence, this layout happens to have the exact same key placement as the workman keyboard layout. Rest assured though, it is not the same layout.
Oh, you’re still wondering what the difference is? The name, silly!
It is a well-known “fact”, in some circles, that running grep in the C locale is much faster than in UTF-8 locales, the latter being a common default on current client systems.
Indeed, just the other day, a colleague of mine was running something akin to:
grep ‘“event-type-id”:4727’ app.log
app.logis a multi-gigabyte file of JSON lines1, the goal being to quickly see whether a newly-added type of event is seen. Almost immediately, someone jumped in to recommend running grep in the C locale, instead of the default UTF-8 locale, for Guaranteed Extra Speediness™.
I wondered whether this was indeed good advice. (TL;DR: using the C locale does not help performance in general, or jump to conclusions.)
Alf is a modern, powerful implementation of relational algebra. It brings relational algebra where you don’t necessarily expect it: in shell, in scripting and for building complex software. Alf has an rich set of features. Among them, it allows you to:
Query .json, .csv, .yaml files and convert from one format to the other with ease,
Query SQL databases with a sounder and more powerful query language than SQL itself,
Export structured and so-called “semi-structured” query results in various exchange formats,
Query multiple data sources as if they were one and only one database,
Create database viewpoints (mostly read-only viewpoints for now), to provide your users with a true database interface while keeping them away from data they may not have access to,
Enjoy a rich set of relational operators and even define your own high-level and domain-specific ones.
Neorg is a tool designed to reimagine organization as you know it. Neo - new, org - organization. Grab some coffee, start writing some notes, let your editor handle the rest.
Why do we need Neorg? There are currently projects designed to clone org-mode from emacs, what is the goal of this project? Whilst those projects are amazing, it’s simply not enough. We need our own, better solution - one that will surpass every other text editor. One that will give you all the bragging rights for using Neovim. Here’s how we’ll do it:
Revise the org format - Simple, very extensible, unambiguous. Will make you feel right at home. Org and markdown have several flaws, but the most notable one is the requirement for complex parsers. I really advise educating yourself on just how bad markdown can get at times; what if we told you it’s possible to eliminate those problems completely, all whilst keeping that familiar markdown feel?
Enter the .norg file format, whose base spec is almost complete. The cross between all the best things from org and the best things from markdown, revised and merged into one.
Keybinds that make sense - vim’s keybind philosophy is unlike any other, and we want to keep that vibe. Keys form a “language”, one that you can speak, not one that you need to learn off by heart.
Infinite extensibility - no, that isn’t a hyperbole. We mean it. Neorg is built upon an insanely modular and configurable backend - keep what you need, throw away what you don’t care about. Use the defaults or change ‘em. You are in control of what code runs and what code doesn’t run.
Logic. Everything has a reason, everything has logical meaning. If there’s a feature, it’s there because it’s necessary, not because two people asked for it.
Everyone 1 and their dog 2 loves Git. I know I do. It works, it’s efficient, it has a brilliant data model, and it sports every feature under the sun. In 13 years of using it, I’ve never found myself needing a feature it didn’t have. Until recently.
But before I tell you about it, let’s talk about GitHub.
Even in the age of smartphones I still prefer to check the calendar on my computer and I’ve often been disappointed by the horrible default calendars that ship with some operating systems (e.g. macOS’s calendar accessible via its systray).
Fortunately for us, Emacs users, we always have access to a proper calendar regardless of our OS and desktop environment (if any) -
M-x calendar. By default it looks something like this:
A post-modern text editor.
While discussing with fellow developers, I was asked the following question a few times: We spend most of our time as developers thinking, not editing code; so, why invest time into mastering a complicated code editor, and why lose some cognitive resources on thinking about text editing instead of about the real programming problem?
I think this point of view is misguided, for a few reasons:
Despite their name, code editors are not only about editing, but also about code navigation. Programming is a hard task partly due to the huge amount of context we have to keep in mind, and being able to quickly navigate code helps us refresh that context, by looking at definitions, implementations, and comments.
Although code editing itself is not the most important part of programming, it still takes non-negligible time to perform, and can be optimized by using better tools.
Finally, a programming career spans a few decades, so investing a few weeks to improving our editing and navigating speed is definitely worth it.
I have heard about Neovim for a long time. I can say that I really appreciate and adopt the ideas of Neovim – it’s more progressive, embraces open source community, and tries to make Neovim approachable to more developers.
However, for its functionality, I didn’t see much difference between Vim. There are various reasons. Firstly, Neovim is a drop-in Vim, so even the plugins could compat each other without much modification, if it is not implemented with Vim or Neovim specific feature. And Neovim somehow pushes Vim to evolve and release similar improvement. e.g., asynchronous job. For an end-user without much deeper knowledge, the biggest differences might be
XDG_PATHbased directory and
People often wonder why SQLite does not use the Git version control system like everybody else. This article attempts to answer that question. Also, in section 3, this article provides hints to Git users about how they can easily access the SQLite source code.
This article is not a comparison between Fossil and Git. See https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki for one comparison of the two systems. Other third-party comparisons are available as well - use a search engine to find them.
This article is not advocating that you switch your projects away from Git. You can use whatever version control system you want. If you are perfectly happy with Git, then by all means keep using Git. But, if Git is not working well for you or you are wondering if it can be improved or if there is something better, then maybe try to understand the perspectives presented below. Use the insights thus obtained to find or write a different and better version control system, or to just make improvements to Git itself.
The first stable release of Sublime Text 4 has finally arrived! We’ve worked hard on providing improvements without losing focus on what makes Sublime Text great. There are some new major features that we hope will significantly improve your workflow and a countless number of minor improvements across the board.
str(…)macro to handle them all.
int table = 13; int id = 37; str test1 = str(“SELECT * FROM “, table, ” where person_id “, id); str test2 = str(test1); //copies test1 to test2 str test3 = str(test2, test1); // returns concat of test2 and test1
test2 = test1; // acceptable, but wrong since test2 now points to test1 not copies it.
str(test1); // returns const char to use in printf like functions Ex: puts(str(*test1)); // prints test1;
Once, there was a civilization (the Lisp Machine world) a lot like ours, but more advanced, with greater powers (like symbolic computation, automated learning, and LISP).
Then, in one tragic moment (er, decade - the 1980’s), it was destroyed.
But because of the wisdom of Jor-El (Stall-Man), because he realized that the human race had the capacity for good, he sent us his only son (editor).
His name is Kal-El (elisp). He will call himself Clark Kent (Editor MACroS), but the world will know him as… Superman (Emacs).