git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/3] serialize collection of refs that contain submodule changes

From
Heiko Voigt <hvoigt@hvoigt.net>
Date
Oct 12, 2016, 13:10 UTC
Message-ID
<20161012131027.GB84247@book.hvoigt.net>
In-Reply-To
<CAGZ79kZ5CPTuW2fARDs3BUt89b8H_=P3otZv+Vm5nTV70NLWtg@mail.gmail.com>
On Fri, Oct 07, 2016 at 11:16:31AM -0700, Stefan Beller wrote:
Show 29 quoted lines
> > diff --git a/submodule.c b/submodule.c
> > index 59c9d15905..5044afc2f8 100644
> > --- a/submodule.c
> > +++ b/submodule.c
> > @@ -522,6 +522,13 @@ static int has_remote(const char *refname, const struct object_id *oid,
> >         return 1;
> >  }
> >
> > +static int append_hash_to_argv(const unsigned char sha1[20], void *data)
> > +{
> > +       struct argv_array *argv = (struct argv_array *) data;
> > +       argv_array_push(argv, sha1_to_hex(sha1));
> 
> Nit of the day:
> When using the struct child-process, we have the oldstyle argv NULL
> terminated array as
> well as the new style args argv_array. So in that context we'd prefer
> `args` as a name for
> argv_array as that helps to distinguish from the old array type.
> Here however `argv` seems to be a reasonable name, in fact whenever we
> do not deal with
> child processes, we seem to not like the `args` name:
> 
>     $ git grep argv_array |wc -l
>     577
>     $ git grep argv_array |grep args |wc -l
>     293
> 
> The rest looks good to me. :)

Thanks. So I do not completely get what you are suggesting: args or kept it the way it is? Since in the end you are saying it is ok here ;) I mainly chose this name because I am substituting the argv variable which is already called 'argv' with this array. That might also be the reason why in so many locations with struct child_processe's we have the 'argv' name: Because they initially started with the old-style NULL terminated array.

I am fine with it either way. Just tell me what you like :)
Cheers Heiko
Previous: Stefan BellerNext: Stefan Beller
Message 11 of 19 in “Speedup finding of unpushed submodules”
  1. 0/3 Speedup finding of unpushed submodulesHeiko Voigt, Oct 7, 2016
  2. 1/3 serialize collection of changed submodulesHeiko Voigt, Oct 7, 2016
  3. Stefan BellerOct 7, 2016
  4. Junio C HamanoOct 10, 2016
  5. Heiko VoigtOct 12, 2016
  6. Junio C HamanoOct 12, 2016
  7. Heiko VoigtOct 13, 2016
  8. Heiko VoigtOct 12, 2016
  9. 2/3 serialize collection of refs that contain submodule changesHeiko Voigt, Oct 7, 2016
  10. Stefan BellerOct 7, 2016
  11. Heiko VoigtOct 12, 2016
  12. Stefan BellerOct 20, 2016
  13. Junio C HamanoOct 10, 2016
  14. 3/3 batch check whether submodule needs pushing into one callHeiko Voigt, Oct 7, 2016
  15. Stefan BellerOct 7, 2016
  16. Junio C HamanoOct 10, 2016
  17. Heiko VoigtOct 12, 2016
  18. Junio C HamanoOct 12, 2016
  19. Heiko VoigtOct 13, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.