On 2021-01-18 at 16:58:56, Utku wrote:
> In my program, I have the file paths, permissions and Git object IDs of
> everything that I want to appear in the next commit. Hence, I want to
> create a commit without creating an index file.
> 
> Essentially it's like to combining `--cacheinfo` from `update-index`
> with `commit` like:
> 
> 	git commit \
> 		-m "Commit message" \
> 		--branch my-branch \
> 		--cacheinfo "100644,0123456789abcdef0123456789abcdef01234567,path/to/first/file” \
> 		--cacheinfo "100755,123456789abcdef0123456789abcdef012345670,path/to/second/file” \
> 		--cacheinfo "100644,23456789abcdef0123456789abcdef0123456701,path/to/third/file"
> 
> In this example, the command would not read the index file, but would
> get the information necessary to create the commit tree as arguments (or
> from STDIN). The command would handle recursively creating trees for the
> intermediate directories. The object ID for the final tree would be used
> for the `tree` field of the commit.

You could use git mktree, git commit-tree, and git update-ref for this.
If you have the object IDs for all the existing blobs and trees, then
you can create any necessary trees, pass the root tree to git
commit-tree, and then use git update-ref to update the branch from the
old value to the new value.

Note that if you're doing this in an otherwise busy repository, you
should definitely specify the old value of the ref to avoid a race
condition where someone else updates it at the same time.

If this seems like a lot of inconvenient work, then you'll see why we
have the index.

If you just want to create a commit without modifying the _main_ index
file, then you can use the GIT_INDEX_FILE environment variable to use a
temporary file as the index and then read data into there and commit
using git read-tree, git update-index, git commit-tree, and git
update-ref.  We do that elsewhere in Git, and this will definitely be
easier than writing your own trees using git mktree.

> So I guess this is the best it gets? If I wanna make it better, I guess
> I will need to use libgit2?

This may be slightly easier with libgit2, depending on your needs.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US