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

["Martin Ågren" <martin.agren@gmail.com>]

On 3 August 2017 at 19:44, Junio C Hamano <gitster@pobox.com> wrote:
> 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