git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Caleb White <cdwhite3@pm.me>
To: Taylor Blau <me@ttaylorr.com>
Cc: phillip.wood@dunelm.org.uk, git@vger.kernel.org,
	Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v2 1/5] worktree: add CLI/config options for relative path linking
Date: Wed, 30 Oct 2024 20:21:28 +0000	[thread overview]
Message-ID: <D59F4X1I5COT.1QECM7J128ZIG@pm.me> (raw)
In-Reply-To: <ZyKUEbXedFuzY9Oz@nand.local>

On Wed Oct 30, 2024 at 3:16 PM CDT, Taylor Blau wrote:
> On Wed, Oct 30, 2024 at 05:27:33AM +0000, Caleb White wrote:
>> >> diff --git a/builtin/worktree.c b/builtin/worktree.c
>> >> index dae63dedf4cac2621f51f95a39aa456b33acd894..c1130be5890c905c0b648782a834eb8dfcd79ba5 100644
>> >> --- a/builtin/worktree.c
>> >> +++ b/builtin/worktree.c
>> >> @@ -134,6 +134,9 @@ static int git_worktree_config(const char *var, const char *value,
>> >>   	if (!strcmp(var, "worktree.guessremote")) {
>> >>   		guess_remote = git_config_bool(var, value);
>> >>   		return 0;
>> >> +	} else if (!strcmp(var, "worktree.userelativepaths")) {
>> >> +		use_relative_paths = git_config_bool(var, value);
>> >
>> > As we're trying to remove global variables from libgit.a as part of the
>> > libification effort I'd be much happier if "use_relative_paths" was
>> > declared as a "static int" in this file and then passed down to the
>> > functions that need it rather than declaring it as a global in "worktree.c".
>>
>> I can create a getter/setter in the worktree API to handle this, but
>> I'd rather not pass it as an argument to every function that needs it as
>> that would be a lot of changes. All of these functions would need their
>> signatures updated to include the new parameter:
>>
>> - `add_worktree()`
>> - `update_worktree_location()`
>> - `repair_worktree_at_path()`
>> - `repair_worktrees()`
>> - `repair_worktree()`
>> - `write_worktree_linking_files()`
>
> There is no reason to have a "getter" and "setter" for a extern'd
> variable.
>
> I agree that it would be preferable to have use_relative_paths be a
> static int within this compilation unit and to pass it to the above
> functions.

If I created a getter/setter then the variable would no longer be
extern'd.

To be clear, you're advocating that I change the function signature
for all of the functions listed above to include the new parameter? That
seems like a lot of parameter bloat when I could just set the variable
in this compilation unit and access it directly in the
`write_worktree_linking_files()` function.

Best,
Caleb


  reply	other threads:[~2024-10-30 20:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28 19:09 [PATCH v2 0/5] Allow relative worktree linking to be configured by the user Caleb White
2024-10-28 19:09 ` [PATCH v2 1/5] worktree: add CLI/config options for relative path linking Caleb White
2024-10-29 14:52   ` Phillip Wood
2024-10-30  5:27     ` Caleb White
2024-10-30 20:16       ` Taylor Blau
2024-10-30 20:21         ` Caleb White [this message]
2024-10-30 20:30           ` phillip.wood123
2024-10-30 20:36             ` Caleb White
2024-10-29 18:42   ` Taylor Blau
2024-10-30  5:07     ` Caleb White
2024-10-28 19:09 ` [PATCH v2 2/5] worktree: add `write_worktree_linking_files` function Caleb White
2024-10-29 14:52   ` Phillip Wood
2024-10-29 22:55     ` Taylor Blau
2024-10-30  5:38       ` Caleb White
2024-10-30  5:30     ` Caleb White
2024-10-28 19:09 ` [PATCH v2 3/5] worktree: add tests for worktrees with relative paths Caleb White
2024-10-29 14:52   ` Phillip Wood
2024-10-29 14:58     ` Caleb White
2024-10-29 15:43       ` phillip.wood123
2024-10-30  5:10         ` Caleb White
2024-10-29 23:00   ` Taylor Blau
2024-10-30  4:16     ` Caleb White
2024-10-28 19:10 ` [PATCH v2 4/5] setup: correctly reinitialize repository version Caleb White
2024-10-28 19:10 ` [PATCH v2 5/5] worktree: add `relativeWorktrees` extension Caleb White
2024-10-29 14:55 ` [PATCH v2 0/5] Allow relative worktree linking to be configured by the user Phillip Wood
2024-10-30  5:13   ` Caleb White

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=D59F4X1I5COT.1QECM7J128ZIG@pm.me \
    --to=cdwhite3@pm.me \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).