zunzuncito - git

A plethora of bug fixes

2024-10-14T20:33:27+02:00

For whatever reason I’ve been uncovering software bugs at an unprecedented rate in the past 10 days. This is by no means a bad thing, I enjoy hunting down and fixing bugs, but it does mean that the additional overhead of drafting a post about each bug becomes a bit too much. So instead here’s a quick overview - the linked patches and merge requests will have more information, if you are interested.</p>

Trash size calculation in KIO</h3>
I noticed this one pretty much right after starting to use Dolphin</a> but did not end up looking into it until quite a bit later: when displaying the size of the items in the trash, the application would always show 0 bytes. This would also cause the automated cleanup of items to fail - Dolphin simply believed that the trash was empty.</p>
KDE uses the KIO</a> framework to provide management of the trash. A recent commit</a> had changed the construction of a QDirIterator</a> in a way that would make it ignore all items when iterating over the trash directory. Thankfully the fix was straightforward and it was merged quickly</a>.</p>

git-shortlog(1) segfaults outside of a git repository</h3>
This one I uncovered as I was writing a small script to give me an overview of commit authors in all the git repositories I had cloned locally. I was happily scanning through my source directory using the `--author</code></a> flag for git-shortlog(1)</code> to generate this, fully expecting git to complain about the few non-git directories I had. Instead of complaints, however, I got a segfault.</p>`
`Turns out that a` `change back in May</a> stopped setting SHA1 as the default object hash. This was done to progress the slow-moving transition to stronger hash functions</a> but inadvertently broke git-shortlog(1)</code> whose argument parsing machinery expected a default hash algorithm to be set. I sent a patch</a> upstream.</p>`

An infinite loop in plasmashell</h3> I regularly use the Activities</a> functionality in Plasma 6 and switch through my activities using Plasma’s built-in activity manager. A couple of days ago I managed to make plasmashell</code>, the provider for Plasma’s desktop and task bar, freeze - I had hit the “up arrow” key in the activity filter text box when there were no results visible. This was perfectly reproducible, so I went to investigate.</p> The cause of the issue was a do-while construct not handling a specific sentinel value, making it loop infinitely. For this one I also opened a merge request</a> upstream.</p>



Better hunk headers with gitattributes(5)
2021-08-11T16:41:49+02:00
Yesterday whilst catching up on the Git mailing list I stumbled upon this
patch</a>
proposing to improve the hunk header regex for Java. I had never paid much
attention to how git-diff(1)</code></a> finds the
right method signature to show in the headers though I was vaguely aware of a
bunch of regexes for different languages.</p>
Turns out that by default, as explained in the manual for
gitattributes(5)</code></a>,
git-diff(1)</code> emulates the behaviour of GNU diff -p</code> and does not</strong> consult
any of the language-specific regular expressions. This came as a bit of a
surprise to me, as Git usually has relatively sane and extensive defaults. Why
define all these regexes and then not use them by default?</p>
Perhaps one reason is that it is hard to tell when to use which. Git can only
look at the filename, and not all shell scripts share the .sh</code> ending, for
example. Surely it would not be too invasive, however, to define sensible
defaults for, say, files ending in .py</code> or .rs</code>.</p>
In any case I updated my ~/.config/git/attributes</code> with the following, and am
now enjoying better hunk headers across the board:</p>
*.c	diff=cpp
*.cpp	diff=cpp
*.go	diff=go
*.md	diff=markdown
*.pl	diff=perl
*.py	diff=python
*.rs	diff=rust
*.sh	diff=bash
*.tex	diff=tex
</code></pre>
The markdown setting is especially neat since it will now display the nearest
section right in the diff, like so:</p>
--- a/posts/weltschmerz.md
+++ b/posts/weltschmerz.md
@@ -24,6 +24,10 @@ ## Download
</code></pre>


git-am(1) and mail sorting
2021-07-25T16:58:29+02:00
In the previous post</a>
 I talked about a couple of
different ways to apply patches with mutt(1)</code> or neomutt(1)</code>. Turns out
Maildir</code> might not be the best format to use for git-am(1)</code> because its
files are not guaranteed to be in any specific order (per
spec</a> they need only carry unique names).</p>
As git-am(1)</code> does not sort its input, patches might be applied in the wrong
order. This came up on the mailing list as well, all the way
back in 2013</a>.
A fix specific to Maildir</code> files created by mutt(1)</code> was added in
18505c3</code></a>.</p>
Sadly neomutt(1)</code> changed this format 5 years ago, removing the sequence number
that git-am(1)</code> relies on in commit
75b3708</code></a>
and replacing it with a call to mutt_rand64()</code>. I can only assume no one is
using neomutt(1)</code> to export patches to Maildir</code>, since having patches applied
in the wrong order is a pretty significant problem.</p>
For now I recommend using the mbox</code> format instead when exporting patches.
Whilst that doesn’t guarantee a specific order either, usually mail clients are
nice enough to export mails to mbox</code> in the order they are shown.</p>
The core issue remains until git-am(1)</code> learns to sort mails itself.</p>


Applying patches with mutt(1)
2021-07-23T22:37:17+02:00
When maintaining a project sooner or later there comes the time when you need to
apply patches that have been submitted to you. Assuming a patch-based workflow,
those are going to be one patch per mail, possibly connected in a thread.
There’s lots of different ways of getting those patches to their final
destination, git-am(1)</code></a>, and in this post I
want to take a look at ones that work well with mutt(1)</code></a> or
neomutt(1)</code></a> since that is what I use.</p>
I want to rely on the default bindings as much as possible. All mentioned
bindings should work out of the box.</em></p>
Applying a single patch is very straightforward: Select the mail in the pager
and hit |</code> to pipe it to an external command.  This command will be some
variation of git-am(1)</code>, perhaps git am -s</code> to also add a Signed-off-by</code>
trailer.</p>
What if you want to apply a patch series, however? An obvious solution would be
to pipe each message in the thread to git-am(1)</code>. The <pipe-message></code> command
we invoked earlier with |</code> only applies to the currently selected message, so
we can’t use that on the whole thread. Instead we can tag the whole thread using
<Esc>t</code>, then use the <tag-prefix></code> command ;</code> followed by |</code> to send all
tagged messages to git-am(1)</code>.</p>
There’s two problems with this, though. The first is that depending on the setting
of pipe_split</code></a>,
git-am(1)</code> might only apply the first patch in the series. This is the case if
pipe_split</code> is set to the default of no</code>; mutt(1)</code> will then concatenate the
messages before sending them to the external command. Sadly this concatenated
format is slightly different from the mbox</code> format that git-am(1)</code> expects,
making it not see anything past the first patch.</p>
With pipe_split</code> set to yes</code>, mutt(1)</code> spawns one process per tagged mail
instead, applying all patches correctly. Now that git-am(1)</code> is spawned once
per mail, however, you lose its atomicity: Neither ORIG_HEAD</code> will be set
correctly, nor will --abort</code> go back to the original branch.</p>
This might not be a big issue, but I am not a fan. Thankfully git-am(1)</code>
supports reading patches from mbox</code> files or Maildir</code> structures. So instead
of piping mails to git-am(1)</code> via <pipe-message></code>, let’s save them to the
current directory: With the thread still tagged, ;C</code> (<tag-prefix></code> followed
by <copy-message></code>) will save a copy of it under a given path. Now you can
apply the series by hitting !</code> and running git am -s <path></code>. This works with
mbox_type</code></a> set to
either mbox</code> or Maildir</code> (but see № 9</a>
).</p>
Of course there is no need to rely on the default bindings, especially if you
need to do this kind of thing very often. mutt(1)</code> is easily customizable,
making it possible to bind the entire chain of actions to just one keystroke.
If you’re interested in a more detailed examination of a patch-based workflow
with mutt(1)</code>, check out this
post</a>
by Greg Kroah-Hartman.</p>


Use git-send-email(1) only to send
2021-06-25T18:25:34+02:00
Even though git-send-email(1)</code></a> calls
git-format-patch(1)</code></a> if you
provide a revision list, oftentimes when submitting a patch series you should
instead run git-format-patch(1)</code> first, and later use git-send-email(1)</code> only
to submit the files it generated. There’s a bunch of reasons for this.</p>


send-email</code> is built chiefly for mail submission, not patch formatting.
There is no way to pass options meant for format-patch</code>, meaning that
you miss out on really good features like
--cover-letter</code></a>
or
--interdiff</code></a>.</p>
</li>

If you use
--annotate</code></a>
or decide to edit the mail body, you will lose all changes if you quit before
sending. You can’t save your work and continue writing the mail later either.
Once you call send-email</code>, you’re committed; It’s all or nothing.</p>
</li>

--compose</code></a>
gets you a worse version of format-patch</code>’s --cover-letter</code>. No diffstat is
included by default, and the same problems as in 2) apply.</p>
</li>

format-patch</code> outputs text files for you to browse and edit. This can be
done on your own time and with your own tools, without the send-email</code> prompt
nagging and stressing you.</p>
</li>
</ol>
Providing a convenient way of quickly sending out small patches makes sense, but
all in all I think the inclusion of formatting in git-send-email(1)</code> is a
glaring misfeature. Hiding git-format-patch(1)</code> away from the user makes
git-send-email(1)</code> intransparent and, worse, really clunky to use for regular
patch workflows.</p>
Sadly, git-send-email.io</a> still tells newcomers to
use only</strong> get-send-email(1)</code>, without even mentioning git-format-patch(1)</code>.
This won’t change</a> any time soon, either.</p>
That is a shame. Guiding people to a worse workflow will not increase the
standing of mail-based processes. For now I’d recommend linking newcomers this
section</a> of
Git’s own contribution tutorial instead.</p>


Patch workflows and git branch -d
2021-06-13T20:22:51+02:00
The notion of a “merged” branch is highly dependent on the
workflow</a> used for a project. I was
wanting to clean up some topic branches in my copy of git.git today, but git branch -d</code> refused to delete them, pointing out that they were not yet merged.</p>
I knew for a fact that they were, which made me look up how git branch -d</code>
actually determines that. The manual is not entirely clear, but a
comment</a>
in the code pointed out that git constructs the merge base of the branch and its
upstream (or HEAD</code> if there is none) and checks whether the branch is reachable
from that merge base.</p>
In a patch workflow, this will generally not be true. A lot of things may
happen to your patches before inclusion, and with git.git they will get at least
one other sign-off. They’ll be recorded in a merge commit, but it will not have
your original branch as one of its parents.</p>
Therefore, neither git branch -d</code> nor git branch --merged</code> will report your
branch as merged. Both of these tools are built for the merge workflow instead.</p>
To see if your work was merged in patch-based workflows, use
git-cherry(1)</code></a>. Then you can safely
force deletion of the branch with git branch -D</code></p>