Re: [PATCH v3 1/7] builtin.h: take over documentation from api-builtin.txt

From: Martin Ågren <martin.agren@gmail.com>
Date: Aug 4, 2017, 04:18 UTC
Message-ID: <CAN0heSrP=HeUcpfwXS9DyzCYCnCCocyV4iCHyAxrYPmW=LgZ+g@mail.gmail.com>
In-Reply-To: <xmqqpoccpmux.fsf@gitster.mtv.corp.google.com>

On 3 August 2017 at 19:44, Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

> Martin Ågren <martin.agren@gmail.com> writes:
>> + * . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
>
> Not a new problem but it will become much easier to follow if we
> moved this item between the "implement cmd_foo()" and "declare
> cmd_foo in builtin.h", like so:
>
>  . Define the implementation of the built-in command `foo` with
>    signature:
>
>         int cmd_foo(int argc, const char **argv, const char *prefix);
>
>    in a new file `builtin/foo.c`.
>
>  . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
>
> Alternatively, we may merge these two into one item (i.e. "in a new
> file `builtin/foo.c` and add `builtin/foo.o` to ...").
>
> But of course, this patch 1/7 should not do any of the above.  I am
> suggesting a possible future clean-up for anybody on the list
> listening from sidelines, and you do not have to be the person who
> does it.

Thank you. If this series needs to be rerolled, I could do it as patch 2. And if not, I could try to remember to do it once this series has landed. A that point in time, I'd also like to try changing other commands ("git branch") similar to "git tag" (although maybe your suggestion above shouldn't be part of that series, but go on its own).

Since this is my first code contribution to Git, I'll ask about this part of SubmittingPatches:

"After the list reached a consensus that it is a good idea to apply the patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the list [*2*] for inclusion."

I will boldly assume that I should not be doing this. It seems to me this doesn't happen very often or not at all -- possibly because you tend to be involved in virtually all threads anyway, before the list reaches a consensus.

Which brings me to my final point: Thanks for your very helpful feedback throughout all three versions and even more thanks for your work on Git. I find it amazing how much time you are able to constantly spend on all aspects -- "high and low" -- of Git. It goes a long way to explaining how Git can be so very useful. Thanks a lot!

Martin