On 04-Jun-2021, at 13:51, Christian Couder <christian.couder@xxxxxxxxx> wrote:
>
> On Wed, Jun 2, 2021 at 3:13 PM Atharva Raykar <raykar.ath@xxxxxxxxx> wrote:
>
>> +static void show_fetch_remotes(FILE *output, const char *sm_name, const char *git_dir_path)
>> +{
>> + struct child_process cp_remote = CHILD_PROCESS_INIT;
>> + struct strbuf sb_remote_out = STRBUF_INIT;
>> +
>> + cp_remote.git_cmd = 1;
>> + strvec_pushf(&cp_remote.env_array,
>> + "GIT_DIR=%s", git_dir_path);
>> + strvec_push(&cp_remote.env_array, "GIT_WORK_TREE=.");
>> + strvec_pushl(&cp_remote.args, "remote", "-v", NULL);
>> + if (!capture_command(&cp_remote, &sb_remote_out, 0)) {
>> + char *line;
>> + char *begin = sb_remote_out.buf;
>> + char *end = sb_remote_out.buf + sb_remote_out.len;
>> + while (begin != end && (line = get_next_line(begin, end))) {
>> + char *name, *url, *tail;
>> + name = parse_token(&begin, line);
>> + url = parse_token(&begin, line);
>> + tail = parse_token(&begin, line);
>
> Sorry for not replying to your earlier message, but I think it's a bit
> better to save a line with:
>
> char *name = parse_token(&begin, line);
> char *url = parse_token(&begin, line);
> char *tail = parse_token(&begin, line);
Alright.
>> + if (!memcmp(tail, "(fetch)", 7))
>> + fprintf(output, " %s\t%s\n", name, url);
>> + free(url);
>> + free(name);
>> + free(tail);
>> + }
>> + }
>> +
>> + strbuf_release(&sb_remote_out);
>> +}
>> +
>> +static int add_submodule(const struct add_data *info)
>> +{
>> + char *submod_gitdir_path;
>> + /* perhaps the path already exists and is already a git repo, else clone it */
>> + if (is_directory(info->sm_path)) {
>> + printf("sm_path=%s\n", info->sm_path);
>
> I don't see which shell code the above printf(...) instruction is
> replacing. That's why I asked if it's some debugging leftover.
Oh, my bad. It is a leftover debugging statement. Please excuse
my temporary blindness to it (:
> [...]
>
>> + if (info->dissociate)
>> + strvec_push(&clone_args, "--dissociate");
>> + if (info->depth >= 0)
>> + strvec_pushf(&clone_args, "--depth=%d", info->depth);
>
> It's ok if there is a blank line here.
OK. Makes sense.
>> + if (module_clone(clone_args.nr, clone_args.v, info->prefix)) {
>> + strvec_clear(&clone_args);
>> + return -1;
>> + }
>> + strvec_clear(&clone_args);
>
>> +static int add_clone(int argc, const char **argv, const char *prefix)
>> +{
>> + const char *branch = NULL, *sm_path = NULL;
>> + const char *wt_prefix = NULL, *realrepo = NULL;
>> + const char *reference = NULL, *sm_name = NULL;
>> + int force = 0, quiet = 0, dissociate = 0, depth = -1, progress = 0;
>> + struct add_data info = ADD_DATA_INIT;
>
> Maybe: s/info/add_data/
'info' was the local convention for naming similar structures that
held the flag values (like summary_cb, module_cb, deinit_cb etc).
The exception to the above is 'struct submodule_update_clone', which
was named as 'suc'. It did not follow the *_cb naming convention,
presumably because it was not used as a parameter passed to any
*_cb() function.
Since 'struct add_data' is more similar to the latter (as it is not
used in any callback function) I guess it would be okay to name it
differently and more descriptively as 'add_data'?
> Also it seems that in many cases it's a bit wasteful to use new
> variables for option parsing and then to copy them into the add_data
> struct when the field of the add_data struct could be used directly
> for option parsing...
>
>> + struct option options[] = {
>> + OPT_STRING('b', "branch", &branch,
>
> ...for example, here maybe `&add_data.branch` could be used instead of
> `&branch`...
I thought of this too, but decided to stick to the surrounding
convention, where a new variable is used and then assigned to the
struct.
I had a looked at the file again, and turns out...
OPT_STRING_LIST(0, "reference", &suc.references, N_("repo"),
N_("reference repository")),
OPT_BOOL(0, "dissociate", &suc.dissociate,
N_("use --reference only while cloning")),
OPT_STRING(0, "depth", &suc.depth, "<depth>",
N_("create a shallow clone truncated to the "
"specified number of revisions")),
... update_clone() is the exception again.
So there is precedent, and I'd rather follow what you suggested,
because that looks much better to me, and saves a lot of redundant
code.
>> + N_("branch"),
>> + N_("branch of repository to checkout on cloning")),
>
> [...]
>
>> + info.branch = branch;
>
> ...so that the above line would not be needed.
Yes, although I might still need to use an extra variable for
booleans, like 'progress' or 'dissociate', because of the need
to use !! to make it either 1 or 0. I am not too familiar with
why doing that would be important in this context, but since
this is the convention, I'll keep it intact.
