Re: [PATCH v6 11/11] builtin/history: implement "split" subcommand
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Dec 19, 2025, 13:00 UTC
- 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:
Show 24 quoted lines
> 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