| Message ID | 20230330112133.4437-2-oystwa@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | branch, for-each-ref: add option to omit empty lines | expand |
Øystein Walle <oystwa@gmail.com> 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@gmail.com> > --- > 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@gmail.com/ 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. > ref-filter.h | 1 - > ref-filter.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/ref-filter.h b/ref-filter.h > index aa0eea4ecf..0f4183233a 100644 > --- a/ref-filter.h > +++ b/ref-filter.h > @@ -75,7 +75,6 @@ struct ref_format { > const char *format; > const char *rest; > int quote_style; > - int use_rest; > int use_color; > > /* Internal state to ref-filter */ > diff --git a/ref-filter.c b/ref-filter.c > index ed802778da..20e0a72f24 100644 > --- a/ref-filter.c > +++ b/ref-filter.c > @@ -596,7 +596,6 @@ static int rest_atom_parser(struct ref_format *format, > { > if (arg) > return err_no_arg(err, "rest"); > - format->use_rest = 1; > return 0; > }
Junio C Hamano <gitster@pobox.com> writes: > Øystein Walle <oystwa@gmail.com> 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@gmail.com> >> --- >> 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@gmail.com/ > > 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@gmail.com/ but it seems there was no review on the series.
On Thu, 30 Mar 2023 at 17:25, Junio C Hamano <gitster@pobox.com> wrote: > > Junio C Hamano <gitster@pobox.com> writes: > > > Øystein Walle <oystwa@gmail.com> 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@gmail.com> > >> --- > >> 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@gmail.com/ > > > > 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@gmail.com/ > > 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. Øsse
Øystein Walle <oystwa@gmail.com> 于2023年3月31日周五 18:39写道： > > On Thu, 30 Mar 2023 at 17:25, Junio C Hamano <gitster@pobox.com> wrote: > > > > Junio C Hamano <gitster@pobox.com> writes: > > > > > Øystein Walle <oystwa@gmail.com> 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@gmail.com> > > >> --- > > >> 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@gmail.com/ > > > > > > 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@gmail.com/ > > > > 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
Øystein Walle <oystwa@gmail.com> writes: > 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... It probably happened because even by then the previous round v4 was not in 'next' when the later iteration was prepared, and then the topic perhaps died at around the time GSoC of the year finished. As long as the earlier and less ambitious attempt turns out to give us a net positive benefit, these early steps may still advance through 'next' and down to a release.
diff --git a/ref-filter.h b/ref-filter.h index aa0eea4ecf..0f4183233a 100644 --- a/ref-filter.h +++ b/ref-filter.h @@ -75,7 +75,6 @@ struct ref_format { const char *format; const char *rest; int quote_style; - int use_rest; int use_color; /* Internal state to ref-filter */ diff --git a/ref-filter.c b/ref-filter.c index ed802778da..20e0a72f24 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -596,7 +596,6 @@ static int rest_atom_parser(struct ref_format *format, { if (arg) return err_no_arg(err, "rest"); - format->use_rest = 1; return 0; }
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@gmail.com> --- Would be nice to have a link to the email thread here, but I don't know how. ref-filter.h | 1 - ref-filter.c | 1 - 2 files changed, 2 deletions(-)