On Fri, May 5, 2017 at 7:30 PM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
>> +static int git_add_interactive_config(const char *var,
>
> Not git_add_interactive__helper_config()? ;-)
I don't get if you mean this ironically (because of the verbosity) or
if you do think this would be a good name ;P
>> + for (i = 0; i < q->nr; i++) {
>> + struct diff_filepair *p;
>> + p = q->queue[i];
>> + diff_flush_stat(p, options, &stat);
>> + }
>> +
>> + for (i = 0; i < stat.nr; i++) {
>> + int file_index = s->file_count;
>> + for (j = 0; j < s->file_count; j++) {
>> + if (!strcmp(s->files[j].path, stat.files[i]->name)) {
>> + file_index = j;
>> + break;
>> + }
>> + }
>
> So basically, this is looking up in a list whether we saw the file in
> question already, and the reason we have to do that is that we run the
> entire shebang twice, once with the worktree and once with the index.
>
> I wonder whether it would not make sense to switch away s->files from a
> list to a hashmap.
> [...]
> BTW in the first pass, we pretty much know that we only get unique names,
> so the entire lookup is unnecessary and will just increase the time
> complexity from O(n) to O(n^2). So let's avoid that.
>
> By moving to a hashmap, you can even get the second phase down to an
> expected O(n).
How would you go about implementing that hashmap (i.e. what should be
the hash)? Does Git have any interface for it, or is there any example
I can look after in the codebase?
> Apart from using PATH_MAX bytes for most likely only short names: [...]
If not PATH_MAX, what should I go for? Make it a strbuf? I tend to
believe keeping that on the stack would be simpler and more optimal.
> Now that I read this and remember that only WORKTREE and INDEX are handled
> in the callback function: is there actually a use for the NONE enum value?
> I.e. is current_mode read out in any other context than the callback
> function? If there is no other read, then the NONE enum value is just
> confusing.
I just preferred to have a declared non-handled value than leave
something undefined behind. I felt it might avoid headaches in the
future with petty segfaults.
> Why not collapse all three functions into one? It is not like they are
> totally unrelated nor super-long.
To me it is a matter of personal preference to keep them separate. If
there is, however, any technical or project-style-related reason to
get them together, I'll certainly do it.
>> +static void print_modified(void)
>> +{
>> + int i;
>> + struct add_interactive_status s;
>> + const char *modified_fmt = _("%12s %12s %s");
>
> We cannot really translate that...
Apparently, we can. Ævar covered that in his reply.
>> + printf(ADD_INTERACTIVE_HEADER_INDENT);
>> + color_fprintf(stdout, header_color, modified_fmt, _("staged"),
>> + _("unstaged"), _("path"));
>
> I think these _() need to become N_().
I cannot find any call to N_() outside of Perl code. What should that
even do differently?
>> +static void status_cmd(void)
>> +{
>> + print_modified();
>> +}
>
> As long as this function really only calls another function with no
> parameters, let's just drop it. We can call print_modified() instead of
> status_cmd() just as easily.
I thought calling status_cmd() would make that more clear, but I agree
-- the options already make it clear enough,
I agree with all points I did not directly address. And thank you for
the review :)
-- Daniel.