Hi, Josh Triplett wrote: > Part of my motivation, here, is that I'm looking to implement one such > escaping mechanism (in a tool built atop libgit2 that needs to handle > and version arbitrary files), and rather than inventing something > bespoke I'd love to interoperate. And since I've seen various approaches > used in the wild, I didn't want to add Yet Another distinct approach > before starting a design conversation about it. *nod* To be clear, I'm glad you brought it up, among other reasons because it means this discussion becomes available in the list archive for when people are wondering about the same thing in the future. > On Wed, May 19, 2021 at 02:31:00PM -0700, Jonathan Nieder wrote: >> Instead, I recommend doing one of the following, in order from most to >> least preferred: [...] > For the test-case approach, these are potentially workable, though they > only work if you just need a git repo with a given set of semantics, > rather than a binary-identical test case. For cases wanting something binary-indentical, it still seems preferable to check in the individual relevant binary file (e.g., an index file or a packfile) instead of a full repository. In addition to the safety improvement involved, this makes the test case easier to understand. > For the storing-arbitrary-files case, these wouldn't apply. Can you say a little more about the storing-arbitrary-files case? For example, 'bup' is a tool built on top of Git formats that stores arbitrary files without using Git tree objects for it. 'etckeeper' is another tool that stores additional information that Git does not (such as detailed filesystem permissions). If you have a use case in common with other tools, then finding a way to interoperate sounds great. :) The best way to do that is likely to depend on the details of what the family of tools want to do. There are some other filenames that "git fsck" also forbids, so this comes down to more than figuring out how to handle ".git". Thanks, Jonathan
