Re: [PATCH 00/19] Cleanup merge API
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 26, 2019, 14:07 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1907261606570.21907@tvgsbejvaqbjf.bet>
- In-Reply-To
- <xmqq7e85pw3y.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
Show 24 quoted lines
> Elijah Newren <newren@gmail.com> writes: > > > On Thu, Jul 25, 2019 at 11:12 AM Junio C Hamano <gitster@pobox.com> wrote: > > > >> > Stuff I'd most welcome review on: > >> > * Is cache-tree.c the right place for write_tree_from_memory()? > >> > [see patch 7] Should there be docs on how it differs from > >> > write_index_as_tree(), already found in cache-tree? What does > >> > the latter even do? > >> > >> write_index_as_tree() is supposed to write the contents of an index > >> state as a tree object, and return the object ID for the resulting > >> tree. It is the primary interface designed to be used by > >> write-tree. > > > > Other than the last sentence, that also sounds like the description of > > write_index_as_tree() -- at least as best I understood it. > > Yes, I didn't even know merge-recursive had its own variant. I > suspect that back when "merge-recursive in C" was being developed, > it first used "git write-tree" via run_command(), and then just > copied and pasted what was done in the write-tree implementation > without bothering to refactor it into write_index_as_tree() and its > own bits about the unmerged index.
FWIW that matches my understanding (i.e. one of those authors' of "merge-recursive in C").
Thanks, Dscho