Re: fast-import fails in read-only tree

From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Jan 29, 2016, 14:28 UTC
Message-ID: <jwv7fisxyhz.fsf-monnier+gmane.comp.version-control.git@gnu.org>
In-Reply-To: <20160129060802.GA23106@sigill.intra.peff.net>

Show 6 quoted lines

>> I recently discovered that "git fast-import" signals an error if used in
>> a tree to which we do not have write-access, because it tries to create
>> a "objects/pack/tmp_pack_XXX" file even before starting to process
>> the commands.
> The primary goal of fast-import is to write that packfile.  It kind of
> sounds like you are using the wrong tool for the job.

Yes, I realize that. But in some cases it's the best tool available. `fast-import' is very close to being a "generic access API" which can be used instead of something like libgit. I think it'd be good to push it yet a bit closer.

My earlier "cat-blob applied to a tree" issue is another such case.

> Can you elaborate on what you are sending to fast-import (preferably
> with a concrete example)?

I'm sending a stream of "progress <foo>; cat-blob <foo>", basically.

The concrete example is in [BuGit](https://gitlab.com/monnier/bugit), see for example https://gitlab.com/monnier/bugit/commit/3678dcb8830a9c79c6f3404d75d63e6dd07bfe4c

> There may be a way to accomplish the same thing with read-only tools
> like cat-file.

Yes, I switched to using "cat-file --batch" instead, but it's less convenient (I can't intersperse ad-hoc info in the output, the way I can with "progress" in fast-import) and there are cases where the list of files I need to extract cannot be determined without first looking at some of those extracted files (I currently have been able to avoid this in BuGit, luckily).

If I could use "cat-blob" on directories, there would be even more cases where I'd want to use fast-import for read-only operations to reduce the number of Git processes I fork.

        Stefan