Re: [PATCH RFC v2 05/16] cache-tree: allow writing in-memory index as tree
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Sep 3, 2025, 12:19 UTC
- Message-ID
- <aLgyZdXV7TUIx_y9@pks.im>
- In-Reply-To
- <xmqqjz2rs6fk.fsf@gitster.g>
On Mon, Aug 25, 2025 at 09:38:07AM -0700, Junio C Hamano wrote:
Show 22 quoted lines
> Patrick Steinhardt <ps@pks.im> writes: > > > The function `write_in_core_index_as_tree()` takes a repository and > > writes its index into a tree object. What this function cannot do though > > is to take an _arbitrary_ in-memory index. > > > > Introduce a new `struct index_state` parameter so that the caller can > > pass a different index than the one belonging to the repository. This > > will be used in a subsequent commit. > > Nice. > > I wonder if this would also allow us to simplify the code paths for > "git commit -o <pathspec>", where we use a separate temporary index > that gets populated afresh from HEAD, grab the new snapshot for the > paths that match the pathspec, and write it out as a tree to be > wrapped in the new commit (and then the real index is also updated > at these same paths). > > I guess the code paths need to expose what is in the temporary index > to hooks, which means the index file needs to be written out to an > actual on-disk file, so the picture would be a bit different?
Well, the sequencer itself is also writing out the temporary index to disk. Took me quite a while to figure out why the index I wrote always turned out to only contain a subset of the changes I wanted. So I don't really see a reason why we couldn't use the infra for other commands, but cannot say whether or not it would end up improving the status quo.
Patrick