On Wed, Sep 26, 2018 at 02:58:12PM -0400, Jeff King wrote:
> And if we were going to generate something external, would it make more
> sense to write in a structured format like doxygen? I am not a big fan
> of it myself, but at least from there you can generate a more richly
> interconnected set
> > (I am not seriously proposing unbalanced comments, but for
> > longer documenting comments we may want to consider,
> > omitting the asterisk?)
>
> If this is not a serious proposal, then I'll stop wasting
> everybody's time.
I proposed two things, one of which I was not serious about.
The ot
On Wed, Sep 26, 2018 at 01:19:20PM -0700, Junio C Hamano wrote:
> > /**
> > Would we be open to consider another commenting style?
>
> No. You still cannot write */ in that comment section, for example,
> so you cannot do "plain text" still---that is not a great trade off
> to deviate fr
Stefan Beller writes:
>> I agree on both counts. I just like to read these in plain text
>> while I am coding for Git (or reviewing patches coded for Git).
>>
>> The reason why I have mild preference to D/technical/ over in-header
>> doc is only because I find even these asterisks at the left-si
> I agree on both counts. I just like to read these in plain text
> while I am coding for Git (or reviewing patches coded for Git).
>
> The reason why I have mild preference to D/technical/ over in-header
> doc is only because I find even these asterisks at the left-side-end
> distracting; it is n
Jeff King writes:
> Now I'll admit it seems like make-work to me because I would not plan to
> ever look at the formatted output myself. But I guess I don't understand
> the audience for this formatted output. These are APIs internal to Git
> itself. We would not generally want to install gitapi-
On Wed, Sep 26, 2018 at 11:58 AM Jeff King wrote:
> Now I'll admit it seems like make-work to me because I would not plan to
> ever look at the formatted output myself. But I guess I don't understand
> the audience for this formatted output.
I have been watching from the side lines so far, as I
On Wed, Sep 26, 2018 at 08:43:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> While we're on that subject, I'd much prefer if these technical docs and
> other asciidoc-ish stuff we would be manpages build as part of our
> normal "make doc" target. So e.g. this one would be readable via
> something li
On Wed, Sep 26 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Wed, Sep 26 2018, Junio C Hamano wrote:
>>
>>> Jeff King writes:
Yes, please. I think it prevents exactly this sort of confusion. :)
>>>
>>> CodingGuidelines or SubmittingPatches update, perhaps?
>>>
On Wed, Sep 26, 2018 at 11:27:53AM -0700, Junio C Hamano wrote:
> >> diff --git a/Documentation/CodingGuidelines
> >> b/Documentation/CodingGuidelines
> >> index 48aa4edfbd..b54684e807 100644
> >> --- a/Documentation/CodingGuidelines
> >> +++ b/Documentation/CodingGuidelines
> >> @@ -358,7 +358,1
Ævar Arnfjörð Bjarmason writes:
> On Wed, Sep 26 2018, Junio C Hamano wrote:
>
>> Jeff King writes:
>>>
>>> Yes, please. I think it prevents exactly this sort of confusion. :)
>>
>> CodingGuidelines or SubmittingPatches update, perhaps?
>>
>> Documentation/CodingGuidelines | 6 +-
>> 1 file
On Wed, Sep 26 2018, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Sep 25, 2018 at 12:26:44PM -0700, Stefan Beller wrote:
>>
>>> On Sat, Sep 22, 2018 at 5:58 AM Ævar Arnfjörð Bjarmason
>>> wrote:
>>> >
>>> >
>>> > On Fri, Sep 21 2018, Stefan Beller wrote:
>>> >
>>> > > +/*
>>> > > + *
Jeff King writes:
> On Tue, Sep 25, 2018 at 12:26:44PM -0700, Stefan Beller wrote:
>
>> On Sat, Sep 22, 2018 at 5:58 AM Ævar Arnfjörð Bjarmason
>> wrote:
>> >
>> >
>> > On Fri, Sep 21 2018, Stefan Beller wrote:
>> >
>> > > +/*
>> > > + * Apply want to each entry in array, retaining only the entr
On Tue, Sep 25, 2018 at 12:26:44PM -0700, Stefan Beller wrote:
> On Sat, Sep 22, 2018 at 5:58 AM Ævar Arnfjörð Bjarmason
> wrote:
> >
> >
> > On Fri, Sep 21 2018, Stefan Beller wrote:
> >
> > > +/*
> > > + * Apply want to each entry in array, retaining only the entries for
> > > + * which the fun
On Sat, Sep 22, 2018 at 5:58 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Sep 21 2018, Stefan Beller wrote:
>
> > +/*
> > + * Apply want to each entry in array, retaining only the entries for
> > + * which the function returns true. Preserve the order of the entries
> > + * that are retained.
On Fri, Sep 21 2018, Stefan Beller wrote:
> +/*
> + * Apply want to each entry in array, retaining only the entries for
> + * which the function returns true. Preserve the order of the entries
> + * that are retained.
> + */
> +void oid_array_filter(struct oid_array *array,
> +
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
sha1-array.c | 17 +
sha1-array.h | 9 +
2 files changed, 26 insertions(+)
diff --git a/sha1-array.c b/sha1-array.c
index b94e0ec0f5e..d922e94e3fc 100644
--- a/sha1-array.c
+++ b/sha1-array.c
@@ -77,3 +77,20 @@
17 matches
Mail list logo