From: Patrick Steinhardt <ps@pks.im>
Date: Fri, 19 Dec 2025 13:00:12 GMT
Subject: Re: [PATCH v6 11/11] builtin/history: implement "split" subcommand
Message-ID: <aUVMXKT0sqiE8Qx2@pks.im>
In-Reply-To: <48ba9303-45f4-43bf-a257-10d58474096c@gmail.com>

On Wed, Dec 10, 2025 at 09:51:33AM +0000, Phillip Wood wrote:
> On 02/12/2025 18:51, Patrick Steinhardt wrote:
> > On Fri, Nov 21, 2025 at 02:31:14PM +0000, Phillip Wood wrote:
> > > On 27/10/2025 11:33, Patrick Steinhardt wrote:
> > > > +	* Construct the first commit. This is done by taking the original
> > > > +	* commit parent's tree and selectively patching changes from the diff
> > > > +	* between that parent and its child.
> > > > +	*/
> > > > +	repo_git_path_replace(repo, &index_file, "%s", "history-split.index");
> > > > +
> > > > +	read_tree_cmd.git_cmd = 1;
> > > > +	strvec_pushf(&read_tree_cmd.env, "GIT_INDEX_FILE=%s", index_file.buf);
> > > > +	strvec_push(&read_tree_cmd.args, "read-tree");
> > > > +	strvec_push(&read_tree_cmd.args, oid_to_hex(&parent_tree_oid));
> > > > +	ret = run_command(&read_tree_cmd);
> > > 
> > > Why do we need to fork "read-tree" here rather than call unpack_trees()
> > > ourselves?
> > 
> > This is an artifact of how the `run_add_p()` interfaces work. They
> > unfortunately do not work on top of an in-memory index, but they work on
> > an on-disk index.
> 
> Oh I see, but why does that mean we need to fork a subprocess rather than
> writing the index to disc in this process?

Fair indeed. I guess it was laziness because other parts of Git did it
the same way. Anyway, let me change this now.

Patrick