Øystein Walle <oystwa@xxxxxxxxx> 于2023年3月31日周五 18:39写道： > > On Thu, 30 Mar 2023 at 17:25, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > > > Øystein Walle <oystwa@xxxxxxxxx> writes: > > > > > >> use_rest was added in b9dee075eb (ref-filter: add %(rest) atom, > > >> 2021-07-26) but was never used. As far as I can tell it was used in a > > >> later patch that was submitted to the mailing list but never applied. > > >> > > >> Signed-off-by: Øystein Walle <oystwa@xxxxxxxxx> > > >> --- > > >> Would be nice to have a link to the email thread here, but I don't know > > >> how. > > > > > > > > > Here is a link to the patch that led to that commit you cited: > > > > > > https://lore.kernel.org/git/207cc5129649e767036d8467ea7c884c3f664cc7.1627270010.git.gitgitgadget@xxxxxxxxx/ > > > > > > It indeed is cumbersome to add, as the Message-Ids for patches from > > > GitGitGadget tend to be ultra long. > > > > > > But b9dee075eb was the last one in the 5-patch series; I do > > > not see any "later patch there in the thread. > > > > I think there was a follow-up RFC series that was written to use the > > value of the member, cf. > > > > https://lore.kernel.org/git/9c5fddf6885875ccd3ce3f047bb938c77d9bbca2.1628842990.git.gitgitgadget@xxxxxxxxx/ > > > > but it seems there was no review on the series. > > The follow-up series you link to seems to be a superset of the first series, > which is what confused me. This is why I thought perhaps a subset of the latter > series was accepted. But I see now that the dates match that of the first > series, and you even applied it very soon after. Strange choice to include the > first five patches in the follow-up series, then... > > Looked through the git.git log and see that it's not uncommon to reference > patches from lore.kernel.org, so I can do the same. Perhaps in the "footnote > style" to make it easier to digest. That is, if we want to apply this in the > first place... It is a very minor cleanup of something that does no harm. On > the other hand this particlar line of development seems abandoned. > Yes. Originally, I hoped to make all the atoms of cat-file --format compatible with ref-filter, and then make cat-file --format able to use the interface of ref-filter But due to some performance issues, this route is now deprecated. This little %(rest) is no longer useful. > Øsse ZheNing
