Episode: 4591
Title: A Bit of Git
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4591/hpr4591.mp3
Transcribed: 2026-07-31 16:14:39 (official HPR transcript)

---

This is Hacker Public Radio Episode 4591, for 2026-03-09
Today's show is entitled, "A Bit of Git"
The host is Lee and the duration is 00:14:13
The flag is Clean, and the license is CC-BY-SA
The summary is "Lee relates the git adventure that occurred while working on a work logging project"
Hello, I'm Leigh.
Style be relating the experience with the distributed version to troll system, called Get,
that happened this afternoon, 26th of December, we call that day here, Boxing Day.
Phone when it doesn't know, Get was crash by Linda Spenderdick to Vowd's, who is a finish
in the American software developer.
It's also known for being the craternly developer of the Lynette's kernel, which is running
on about 70% of the world's computing devices.
So, this afternoon I sat down and browsed onto the online repository of a project I've been
working on.
The project was a simple work session logger with both desktop and web versions.
The web version uses.net core, which is an open source framework, a little similar to Java,
and the desktop version uses Kirigami, a GUI development framework based on the KDA
management environment, but with libraries that allow the app to run in other environments.
The code hosting service, Get Hub, reminded me I had two outstanding issues to work on.
I sat about addressing those, a did by Claude Code, a professional coding tool that can
be conversed with in-chat, and is able to help with common software development tasks such
as writing debugging and testing code.
And it's just one of a number of such tools available that became possible with advances
in low-cost parallel computing, the accumulation of large amounts of human-produced digital
data and developments in computer science.
In particular, what is known as the Transformer architecture that weighs how different
words in text are related to each other statistically, and by doing this can build a massive
new data set known as a large language model, which can then be used to understand a process
both natural language and computer languages.
Today I made seven changes to the code of my work logging project, each one deserving
a commit, that's when you save the state of the code to the version control system.
First change, add some padding beneath the list of days to left pane, so when a scroll
down to the most recent, it's in the middle rather than hard to reach the bomb.
This was for both the web app and desktop app, then commit.
Second change, in the web app, stop code blocks in the word description going off the right
hand-edge, this requires some CSS tweaks, CSS being short for cascading style sheets,
it's the language that lets you change all the visual style of a web page without having
to adjust all the contents, then commit.
Third change, increase that padding for the web app, because it wasn't as much as I
typed, then commit.
Fourth change, get the web app to render work session notes as marked down rather than plain
text.
It was not even difficult, as a text component has that as an option, then commit.
Fifth change, fixing the Cloud Sync screen, which should regress, to splatting its contents
all over the window, instead of containing them in a mobile dialogue box.
A long bell should have been ringing for me at this point, so I distinctly remembered
fixing this once already.
I kind of assume maybe somehow I'd unfixed it with what I'd just been doing.
Anyway, despite my spy-desense tingling, commit this as well.
Sixth change, I just CSS layout a bit more, as the code blocks were still not responsive
when the browser window was narrowed.
Then commit.
Fifth change, adjust the CSS layout even more, for when the window is very narrow, like
on a mobile phone, then commit.
That was all I wanted to do for the day, it had not taken very long.
These changes were tested, both the web-based and desktop-based versions of the app, both
looked okay, and were behaving well.
So, the next step was to push my changes to the public repository.
This is a place where others can access the source code, download it, and make use of
it themselves, if they want to.
It's not like code hosting platform called GitHub.
There are other such platforms such as GitLab and BitBuckit, so name just a couple.
It is managed by the provider, and for small projects like my one, a free or low-cost
use.
There are also alternative ones like Gitty that can be hosted on your own infrastructure
if you want to have more control over things.
When I tried to push my changes, I got an error though.
I found out my branch had diverged from where I was pushing it to.
This was a classic mistake, I not pulled the code from the public repository prior to
starting work on it.
I just assumed I was working on the latest version of the code.
Then I remembered what had happened a few days ago, Monday to be precise, this been Friday.
I've been using my Dell laptop.
I had a synchronization software called Resilio Sync running on it and seeking all my files
between the mesh of different PC, servers, and laptops I use, and I thought this would
have updated things for me, but apparently I had not done so on this occasion.
So doing a fetch and looking at the log of commits in Graph Form, showed there was already
a fixed and a mode of dialogue issue in the public repository.
Even the fixed and previously was slightly better, because it explicitly made the Sync
dialogue not visible into it needed to be displayed rather than relying on any assumptions.
So two branches of the project had diverged.
At this point, if I had reason to believe other people were working on this code, it would
be necessary to start from the remote version and merge in my changes as new commits.
That would end up with quite a messy history, but there was another way that would keep
the history clean and easy to understand when looking back at these changes.
The operation to be performed was called a rebase.
This let's local commits be replayed one by one on top of the remote branch.
Plato talks about it in an episode of HPR, 2573 for June 13th, 2019, called Foundations
of Git Rebase.
So stepping through my commits, and I got to the one with the modal Sync dialogue box,
this had to be staged but the commits skipped since the fix I mentioned was already in place.
Having done this, the log of commits was very examined and looked now correct, so I pushed
this to GitHub.
At first I thought this was all fine now.
On closer inspection I could see attribution messages had been added, mentioning co-authorship
by the Claude Code to I'd been using.
Normally that would be fine by a reason for pause.
This was because the desktop version of this app, in the cart down form, had been deployed
on flat hub, which is the most common source for obtaining flat packed packages.
These are a new generation of software packages used to install software and Linux distributions.
This type of packaging system has two main advantages, first it's agnostic as to which particular
Linux distribution you're installing the software on, because it includes important dependency
libraries bundled with it.
Secondly, it incorporates sandboxing that limits the privileges the application has on the
system it's installed on.
This reduces potential side effects with the caveat that when privileged access of some
kind is required, this must be allowed for explicitly.
An example might be writing a file onto your home directory, which by default a sandbox
program would not be allowed to do.
Why was I bothered?
Well I remember that flat hub has deliberate policies around distributing code produced
by generative artificial intelligence systems.
And this is for good reason, on my still commercial large language models have been trained
from massive amounts of data that came from the public internet, especially source code
repository such as GitHub.
Arguably systems like Claude have used this information to learn how to program, which
is skill, but it's still plausible it remembers for baitum some of its training material.
In the same way that I remember punished by heart I was taught at the school, even though
I've primarily exposed to those texts to learn the pan's fan different forms of literature
and skills of comprehension and discourse.
If I produced a piece of writing and included word for word, some verse I'd remember
without attributing it to the offer this would be considered intellectual theft.
In the same way, large language models generally use a knowledge of programming to generate
completely new code put together a new ways.
If we exclude trivial common repetitions or idioms, it's likely to be distinct from anything
that existed before.
There's still the danger and LLM-Y output large amounts of someone's work exactly as it was
remembered.
Even open source licenses often demand proper attribution for the original program's work,
so it's basically not okay to redistribute something very close to what they wrote without proper
attribution.
This leads to a legal grey area between what is copying code someone else wrote and what is
termed fair use.
Saying all this, I don't think I've stolen someone else's code, but ering on the side of
both caution and pragmatism, I don't want to advertise too much in the public repository
what tools I've used if there are policy implications.
To fix this required rewriting the git history again,
it includes a way of doing this called filter branch, which could be combined with a text
replacement program called said.
That's SCD.
And speaking of said, I have a repurposed anti-region enclosure.
I got it out of the valves and put an old Android tablet in the face.
It shows a world clock, the weather, and foca flashcards in Dutch and Spanish,
so as well as a Latin conjunction, I know said means thirst in Spanish.
The English command line term said is a program that takes in some input text,
then a pattern, which is basically a string of text that encodes some rules it must apply,
and it produces output having applied those rules.
Unfortunately, the filter branch command that was tried didn't do anything.
The second attempt used the git command called rebase again, along with an exact parameter,
telling it to commit with amendment, a version of the original message,
using said to remove the unwanted mention of Claude.
Looking at the git log provided assurance this had worked.
I thought now this would be all resolved, but no, the history was still divergent
from the remote repository.
Changing the commit messages had again made it look like the changes were on the different branch,
even though the changes themselves were identical.
A normal git push would not work.
Luckily there's a way of overriding this problem by doing what's called a force push.
This is not something that anyone typically should do when the remote repository is shared
or public, since it will invalidate version control for anyone else working on this code.
Because this was quite a new project, and I was pretty sure I was the only person working on it,
and the divergence has happened only recently, I decided to go ahead and update the remote
repository this way anyway.
Finally, there was both for clean history and the commit messages stated just for each change
was not what tools I used.
Here's what I learned about git.
First, rebasing lets you replay commits.
If two branches diverge, you can replay your commits on top of the remote branch,
and keep the history simple.
Second, if conflicts occur with the rebase, they can be solved,
as you have the option to continue skip or abort entirely.
Third, with interactive rebasing, you can do powerful things like run arbitrary commands and each commit.
Useful for amending commit messages, for example.
Fourth, rewriting history changes commit hashes.
So even if the file changed is identical, the history has changed, so this needs to be born in mind.
A force push will rewrite the remote history, but it should be done with caution.
Only few are the only person working on the branch.
You're okay with the published history changing, and you've checked your changes are correct.
Six, using filter branch and said can be a bit tricky.
This is why I did the interactive rebase instead.
Here are the various commands that we used, git status, this checks the current status.
It especially tells you if there are any new on modified files and which of those files have been staged.
git fetch origin, this fetch is the latest history from the remote repository.
git log dash dash one line dash dash graph dash dash all dash dash the correct dash 15.
This draws a graph of the commit history.
git show origin slash main dash dash that or git show some hash and some file name.
Ever of these will show details of the commit, git rebase origin slash main.
This rebase is local commits onto the remote branch.
git add some file, stages of particular file, git rebase dash dash skip, this
skips the next commit when rebasing, git show dash dash, step capital HAAD, or git log dash dash format
equals in double quotes per cent capital B dash one capital HAAD, either of these will check commit message.
git rebase dash i sum hash dash dash exec in single quotes sum command, this runs a command like
git commit dash dash amend when rebasing, git push dash dash force, this does a force push.
I'm to put a reference to these in the show notes.
That's all for now, thanks for listening, bye bye.
You have been listening to Hacker Public Radio at Hacker Public Radio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording podcast, click on our upload link
to find out how easy it is.
Hosting for HPR has been kindly provided by an AnHonestHost.com, the Internet Archive,
rsync.net, and our mirror network.
Unless otherwise stated, today's show is released under a Creative Commons
Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
