From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "D. Ben Knoble" <ben.knoble@gmail.com>,
Robert Coup <robert.coup@koordinates.com>,
Christian Couder <chriscool@tuxfamily.org>,
"Randall S. Becker" <randall.becker@nexbridge.ca>
Subject: Re: [PATCH v3 5/5] remote: announce removal of "branches/" and "remotes/"
Date: Wed, 22 Jan 2025 12:05:53 +0100 [thread overview]
Message-ID: <Z5DRESPpegE41xaT@pks.im> (raw)
In-Reply-To: <xmqqtt9ryi3f.fsf@gitster.g>
On Tue, Jan 21, 2025 at 01:25:56PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/builtin/remote.c b/builtin/remote.c
> > index 1ad3e70a6b..e565b2b3fe 100644
> > --- a/builtin/remote.c
> > +++ b/builtin/remote.c
> > @@ -640,10 +640,12 @@ static int migrate_file(struct remote *remote)
> > strbuf_addf(&buf, "remote.%s.fetch", remote->name);
> > for (i = 0; i < remote->fetch.nr; i++)
> > git_config_set_multivar(buf.buf, remote->fetch.items[i].raw, "^$", 0);
> > +#ifndef WITH_BREAKING_CHANGES
> > if (remote->origin == REMOTE_REMOTES)
> > unlink_or_warn(git_path("remotes/%s", remote->name));
> > else if (remote->origin == REMOTE_BRANCHES)
> > unlink_or_warn(git_path("branches/%s", remote->name));
> > +#endif /* WITH_BREAKING_CHANGES */
> > strbuf_release(&buf);
>
> Interesting. I wonder if our new warning should talk about whatever
> end-user facing interface that triggers this code path. It would
> help them wean themselves away from the old interface, no?
Not quite sure that I understand what you're saying. Is it that we
should tell whether we were reading from "branches/" or "remotes/"? If
so we already do that.
> > diff --git a/remote.c b/remote.c
> > index 10104d11e3..5feb0ae886 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -293,6 +293,7 @@ static void add_instead_of(struct rewrite *rewrite, const char *instead_of)
> > rewrite->instead_of_nr++;
> > }
> >
> > +#ifndef WITH_BREAKING_CHANGES
> > static const char *skip_spaces(const char *s)
> > {
> > while (isspace(*s))
> > @@ -308,6 +309,13 @@ static void read_remotes_file(struct remote_state *remote_state,
> >
> > if (!f)
> > return;
> > +
> > + warning(_("Reading remote from \"remotes/%s\", which is nominated\n"
> > + "for removal. If you still use the \"remotes/\" directory\n"
> > + "it is recommended to migrate to config-based remotes. If\n"
>
> Do we have a way to concisely say "how" to do this? If I am reading
> the caller of migrate_file() in builtin/remote.c, it would be
>
> $ git remote mv foo foo
>
> for any foo in .git/remotes/* or .git/branches/* hierarchy?
>
> Of course they may be an ancient leftover file that the user even no
> longer is aware of having, in which case
>
> $ rm .git/remotes/foo
>
> might be an OK answer, but even then
>
> $ git remote rm foo
>
> would probably be more appropriate.
Very good idea indeed. We also have tests that exercise this behaviour
in t5505 (with the slight exception that it is `git remote rename`, not
`git remote mv`).
Patrick
next prev parent reply other threads:[~2025-01-22 11:06 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 10:56 [PATCH 0/5] remote: announce removal of "branches/" and "remotes/" Patrick Steinhardt
2024-12-11 10:56 ` [PATCH 1/5] Makefile: wire up build option for deprecated features Patrick Steinhardt
2024-12-11 13:06 ` Kristoffer Haugsbakk
2024-12-13 5:26 ` Patrick Steinhardt
2024-12-11 10:56 ` [PATCH 2/5] ci: merge linux-gcc-default into linux-gcc Patrick Steinhardt
2024-12-11 10:56 ` [PATCH 3/5] ci: repurpose "linux-gcc" job for deprecations Patrick Steinhardt
2024-12-11 10:56 ` [PATCH 4/5] builtin/pack-redundant: remove subcommand with breaking changes Patrick Steinhardt
2024-12-11 10:56 ` [PATCH 5/5] remote: announce removal of "branches/" and "remotes/" Patrick Steinhardt
2025-01-06 7:51 ` [PATCH v2 0/5] " Patrick Steinhardt
2025-01-06 7:51 ` [PATCH v2 1/5] Makefile: wire up build option for deprecated features Patrick Steinhardt
2025-01-06 13:20 ` Christian Couder
2025-01-06 13:20 ` Christian Couder
2025-01-06 7:51 ` [PATCH v2 2/5] ci: merge linux-gcc-default into linux-gcc Patrick Steinhardt
2025-01-06 13:25 ` Christian Couder
2025-01-06 15:51 ` Junio C Hamano
2025-01-07 12:48 ` Patrick Steinhardt
2025-01-07 13:54 ` Christian Couder
2025-01-06 7:51 ` [PATCH v2 3/5] ci: repurpose "linux-gcc" job for deprecations Patrick Steinhardt
2025-01-06 7:51 ` [PATCH v2 4/5] builtin/pack-redundant: remove subcommand with breaking changes Patrick Steinhardt
2025-01-06 7:51 ` [PATCH v2 5/5] remote: announce removal of "branches/" and "remotes/" Patrick Steinhardt
2025-01-06 13:24 ` Christian Couder
2025-01-06 15:53 ` Junio C Hamano
2025-01-07 12:48 ` Patrick Steinhardt
2025-01-07 16:40 ` Junio C Hamano
2025-01-07 16:49 ` Junio C Hamano
2025-01-07 16:55 ` rsbecker
2025-01-08 6:36 ` Patrick Steinhardt
2025-01-08 17:09 ` Junio C Hamano
2025-01-09 10:06 ` Patrick Steinhardt
2025-01-09 12:08 ` Robert Coup
2025-01-09 10:20 ` Patrick Steinhardt
2025-01-09 15:54 ` Junio C Hamano
2025-01-06 15:42 ` [PATCH v2 0/5] " Junio C Hamano
2025-01-07 12:48 ` Patrick Steinhardt
2025-01-07 16:36 ` Junio C Hamano
2025-01-20 7:42 ` [PATCH v3 " Patrick Steinhardt
2025-01-20 7:42 ` [PATCH v3 1/5] Makefile: wire up build option for deprecated features Patrick Steinhardt
2025-01-20 7:42 ` [PATCH v3 2/5] ci: merge linux-gcc-default into linux-gcc Patrick Steinhardt
2025-01-20 7:43 ` [PATCH v3 3/5] ci: repurpose "linux-gcc" job for deprecations Patrick Steinhardt
2025-01-20 7:43 ` [PATCH v3 4/5] builtin/pack-redundant: remove subcommand with breaking changes Patrick Steinhardt
2025-01-21 21:09 ` Junio C Hamano
2025-01-20 7:43 ` [PATCH v3 5/5] remote: announce removal of "branches/" and "remotes/" Patrick Steinhardt
2025-01-21 21:25 ` Junio C Hamano
2025-01-22 11:05 ` Patrick Steinhardt [this message]
2025-01-22 17:58 ` Junio C Hamano
2025-01-22 11:31 ` [PATCH v4 0/5] " Patrick Steinhardt
2025-01-22 11:31 ` [PATCH v4 1/5] Makefile: wire up build option for deprecated features Patrick Steinhardt
2025-01-22 11:31 ` [PATCH v4 2/5] ci: merge linux-gcc-default into linux-gcc Patrick Steinhardt
2025-01-22 11:31 ` [PATCH v4 3/5] ci: repurpose "linux-gcc" job for deprecations Patrick Steinhardt
2025-01-22 11:31 ` [PATCH v4 4/5] builtin/pack-redundant: remove subcommand with breaking changes Patrick Steinhardt
2025-01-22 11:31 ` [PATCH v4 5/5] remote: announce removal of "branches/" and "remotes/" Patrick Steinhardt
2025-01-22 20:32 ` Junio C Hamano
2025-02-21 15:26 ` Jakub Wilk
2025-02-21 18:30 ` Junio C Hamano
2025-02-25 7:58 ` Patrick Steinhardt
2025-02-25 23:45 ` Junio C Hamano
2025-02-26 9:21 ` Patrick Steinhardt
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=Z5DRESPpegE41xaT@pks.im \
--to=ps@pks.im \
--cc=ben.knoble@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=randall.becker@nexbridge.ca \
--cc=robert.coup@koordinates.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.