From: Junio C Hamano <gitster@pobox•com>
To: "Rubén Justo" <rjusto@gmail•com>
Cc: Git List <git@vger•kernel.org>, Eric Sunshine <sunshine@sunshineco•com>
Subject: Re: [PATCH] checkout: plug some leaks in git-restore
Date: Thu, 14 Mar 2024 09:45:51 -0700 [thread overview]
Message-ID: <xmqqbk7gwym8.fsf@gitster.g> (raw)
In-Reply-To: <8faa0cd5-25e8-4a8f-ad8b-5fc1b6e5138b@gmail.com> ("Rubén Justo"'s message of "Thu, 14 Mar 2024 08:36:25 +0100")
Rubén Justo <rjusto@gmail•com> writes:
> In git-restore we need to free the pathspec and pathspec_from_file
> values from the struct checkout_opts.
>
> A simple fix could be to free them in cmd_restore, after the call to
> checkout_main returns, like we are doing [1][2] in the sibling function
> cmd_checkout.
>
> However, we can do better.
Quite honestly, my knee-jerk raction against _main_1() was "Yuck".
If the repetition of "here are the things we need to clean up"
shared in the current checkout_main() looks so disturbing, I would
have gone in the opposite direction: the current callers of _main()
will do these clean-up actions after the call to _main() returns, so
bundle them into a helper function and call it from the callers of
_main(), without introducing an extra layer of opacity, and I would
have thought that would be what we would call "doing better".
Even better, shouldn't you be able to do much better by not doing
the _main_1() thing at all? If you look at checkout_main(), the
only way to leave thsi function, aside from die()'s, are "return"
statements to the caller at the very end of the function. You
should be able to, instead of returning, capture the value you
receive from calling either checkout_paths() or checkout_branch(),
and then do the common "clean-up" you stole from existing calls and
moved into _main_1(), and after doing so, return the value you
captured from one of these calls that used to directly return, no?
Perhaps something along this line, which should be an equilvalent to
what your patch did?
builtin/checkout.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git c/builtin/checkout.c w/builtin/checkout.c
index 15293a3013..a8ccdfa1f2 100644
--- c/builtin/checkout.c
+++ w/builtin/checkout.c
@@ -1706,6 +1706,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
struct branch_info *new_branch_info)
{
int parseopt_flags = 0;
+ int retval;
opts->overwrite_ignore = 1;
opts->prefix = prefix;
@@ -1900,9 +1901,16 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
}
if (opts->patch_mode || opts->pathspec.nr)
- return checkout_paths(opts, new_branch_info);
+ retval = checkout_paths(opts, new_branch_info);
else
- return checkout_branch(opts, new_branch_info);
+ retval = checkout_branch(opts, new_branch_info);
+
+ branch_info_release(new_branch_info);
+ clear_pathspec(&opts->pathspec);
+ free(opts->pathspec_from_file);
+ FREE_AND_NULL(options);
+
+ return retval;
}
int cmd_checkout(int argc, const char **argv, const char *prefix)
@@ -1953,10 +1961,6 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
ret = checkout_main(argc, argv, prefix, &opts,
options, checkout_usage, &new_branch_info);
- branch_info_release(&new_branch_info);
- clear_pathspec(&opts.pathspec);
- free(opts.pathspec_from_file);
- FREE_AND_NULL(options);
return ret;
}
@@ -1997,8 +2001,6 @@ int cmd_switch(int argc, const char **argv, const char *prefix)
ret = checkout_main(argc, argv, prefix, &opts,
options, switch_branch_usage, &new_branch_info);
- branch_info_release(&new_branch_info);
- FREE_AND_NULL(options);
return ret;
}
@@ -2036,7 +2038,5 @@ int cmd_restore(int argc, const char **argv, const char *prefix)
ret = checkout_main(argc, argv, prefix, &opts,
options, restore_usage, &new_branch_info);
- branch_info_release(&new_branch_info);
- FREE_AND_NULL(options);
return ret;
}
[Footnote]
It is somewhat funny that we are moving more things into the
checkout_main() common function. Maybe the true culprit of this
mess was that the approach for splitting "switch" and "restore" out
of "checkout" was misdesigned.
People were so loudly against "checkout" that can check out a
branch, or check out files and directories out of a commit, and that
was why these two separate commands to do these two separate things
were created. But instead of two separate functions that do two
separate and unrelated things, and making "checkout" call either one
of these depending on which one of the two separate things it is
asked to do, we ended up in a state where a single function _main()
is shared among the three, which may have solved the "these two are
separate operations and having them crammed together into one
command is confusing from the user's point of view" complaint, but
these two operations are still tightly coupled. The fact that the
things that need to be cleaned up after calling checkout_paths() and
checkout_branch() are identical is quite telling ;-)
next prev parent reply other threads:[~2024-03-14 16:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 1:32 [PATCH] checkout: plug some leaks in git-restore Rubén Justo
2024-03-14 2:39 ` Eric Sunshine
2024-03-14 7:36 ` Rubén Justo
2024-03-14 16:45 ` Junio C Hamano [this message]
2024-03-14 18:08 ` [PATCH v2] " Rubén Justo
2024-03-14 18:57 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbk7gwym8.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=rjusto@gmail$(echo .)com \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox