File: day_521__newlines_in_filenames.mdwn

package info (click to toggle)
git-annex 10.20250416-2
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 73,572 kB
  • sloc: haskell: 90,656; javascript: 9,103; sh: 1,469; makefile: 211; perl: 137; ansic: 44
file content (21 lines) | stat: -rw-r--r-- 1,069 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Unix would be better if filenames could not contain newlines. But they can,
and so today was spent dealing with some technical debt.

The main problem with using git-annex with filenames with newlines is that
`git cat-file --batch` uses a line-based protocol. It would be nice if that
were extended to support `-z` like most of the rest of git does, but I
realized I could work around this by not using batch mode for the rare
filename with a newline. Handling such files will be slower than other
files, but at least it will work.

Then I realized that git-annex has its own problems with its `--batch`
option and files with newlines. So I added support for `-z` to every batchable
command in git-annex, including a couple of commands that did batch input
without a `--batch` option.

Now git-annex should fully support filenames containing newlines, as well 
as anything else. The best thing to do if you have such a file is to
commit it and then `git mv` it to a better name.

Today's work was sponsored by Trenton Cronholm 
[on Patreon](https://patreon.com/joeyh).