When resolving merge conflicts in git, it is, of course, critical that the finally committed result has been manually reviewed to be sensible, complete, and correct. This is why it is particularly absurd that (as of writing, and for many years prior) git always includes the --auto argument when invoking KDiff3 as its mergetool. This causes KDiff3 to save and exit, without allowing the user to review the results of its automatic merge, if it has decided upon unambiguous resolutions for every change.

Note this doesn't imply that KDiff3 decided upon the correct resolution for every change. I've been burned by this on more than one occasion. Don't get me wrong: I'm not saying KDiff3's choices are regularly wrong (they're typically very good). But it is not sufficiently reliable that it can be left to operate without supervision by default—yet, that is how git chooses to operate it.

Now, I realise it's still possible to review the contents of the git index before committing the merge result, but that's considerably less convenient than reviewing at the time of the merge itself: you lose the ability to see where individual changes originated from. And if you're doing a big merge [...]

Read this post

I originally posted about this back in 2018, but the recently released Debian Trixie has removed the git-daemon-sysvinit package. That was what I was originally using to make this work. The following contains updated instructions to utilize inetd, instead.

Some of my personal projects are tracked using private git repositories, hosted on this server. I can access these via ssh, but for a while I've had in mind to make at least a couple of them publicly accessible… somehow. After finally getting around to looking into it, this turns out to be deceptively simple using git-daemon (instructions for Debian distros):

1. Choose the user who will host the repositories, and setup some items in their home folder like so:

   cd ~
   mkdir -p git-daemon/git
   echo "Repositories herein are served publicly by git-daemon." > git-daemon/README
   

2. In the git-daemon/git folder, add a symlink to each of the actual git repository folders you want to make public, with the same <repo>.git name (assuming these are bare repositories). These will become accessible via git://<hostname>/git/<repo> or <repo>.git.

3. Ensure each repository (under the .git folder, if not bare) contains a blank git-daemon-export-ok file: e.g., touch <repo>.git/git-daemon-export-ok. git-daemon will [...]

Read this post

I needed to convert several Subversion repositories to Git. Most of my process for this comes from this post. The following are some condensed steps and additional notes.

1. Work in a new no-metadata folder; this helps keep your working environment isolated, and will let you re-use the users.txt file if you need to do this to multiple repositories. Create the users.txt file and ensure all authors in the repo are listed. To get started, do something like this, where SVN_URL is the URL of the repo:

   svn log -q SVN_URL | awk -F " \\\\| " '/^r/ {print $2" = "$2" <>"}' | sort -u > users.txt
   

   Note that this will preserve spaces in user names, if present (some other snippets you might find are broken and will not). Now edit users.txt and fill in details. You might need to add a (no author) = No Author <no@author.invalid> line, too, if there are any commits which have no author, such as the empty ones created by some techniques that manipulate dump files to purge files.

2. Use git-svn like this (replace SVN_URL with the correct URL) to clone the repo without metadata; add --stdlayout if using standard branch folders, or as many -T, -t [...]

Read this post

I found myself in the unusual situation of having a Subversion repository which was created initially without the usual trunk, branches, and tags folders, but where the team found later that, you know, this newfangled “branches” idea might just come in useful after all. If that's all there was to it, I could have just added those folders in a regular commit and continued on. The tricky part was that we also wanted git-svn compatibility, and for it to recognize branches, it needs the folder structure to be in place from the first commit onward.

Unfortunately, there ain't no easy way to achieve this which also preserves the revision numbers. But it is possible. What I had to do was rewrite the first commit manually:

1. Checkout the original repo at revision 1.
2. Copy all the files to a new repo, but this time place it under a trunk top-level folder, ensuring everything is otherwise identical inside.
3. Also add tags and branches top-level folders.
4. Commit all those using the same commit message as the original.

Now, this commit still doesn't have the same metadata, so I had to then take an svndump of the new repo, and edit that dump so [...]

Read this post

With colleagues at NUS, Singapore, and Strathclyde, UK, we contributed to this study which looked at applying some recent enhancements of QKD analysis techniques to the QEYSSat scenario (among others). Some useful discussions about the state-of-the-art.

T. Islam, J. S. Sidhu, B. L. Higgins, T. Brougham, T. Vergoossen, D. K. L. Oi, T. Jennewein, and A. Ling
Finite-resource performance of small-satellite-based quantum-key-distribution missions
PRX Quantum 5, 030101 (2024)

Read this post

When constructing an optical system for communicating using polarized photons, it's critical that components and subsystems be accurately and comprehensively characterized. Especially so if that system is designed to be sent into space, where any corrections after the fact are, at best, extremely difficult (just ask Hubble). With this in mind, we developed a polarization characterization platform for optical devices based on an imaging polarimeter attached to a six-axis robot arm. In this paper, we describe the device and its performance for characterizing some sample test devices, including a large lens designed for a quantum optical transmitter to a receiver satellite.

Read this post