Re: [PATCH 2/3] add--interactive: add builtin helper for interactive add
- From
Daniel Ferreira (theiostream) <bnmvco@gmail.com>
- Date
- May 5, 2017, 23:13 UTC
- Message-ID
- <CAEA2_RKzUdSPP4bBvGiFVfNnAY3wwp+0LYriC4q5XfCP-1-F4w@mail.gmail.com>
- In-Reply-To
- <alpine.DEB.2.21.1.1705052328380.146734@virtualbox>
On Fri, May 5, 2017 at 7:30 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
Show 28 quoted lines
>> + 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.
Show 5 quoted lines
> 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.
Show 7 quoted lines
>> +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.
Show 5 quoted lines
>> + 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?
Show 8 quoted lines
>> +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.