Re: Standardized escaping to store a .git in git?

[Jonathan Nieder <jrnieder@gmail.com>]

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