| Message ID | 20250106-pks-remote-branches-deprecation-v2-0-2ce87c053536@pks.im (mailing list archive) |
|---|---|
| Headers | show |
| Series | remote: announce removal of "branches/" and "remotes/" | expand |
Patrick Steinhardt <ps@pks.im> writes: > back when Git was in its infancy, remotes were configured via separate > files in "branches/" (back in 2005). This mechanism was replaced later > that year with the "remotes/" directory. These mechanism have evenutally > been replaced by config-based remotes,... Just a historical note, as I am not sure how much of it still matters. In all of the above "replaced" is an incorrect verb to use. "A more-powerful-but-different mechanism to do the same and more was introduced later" is a fair statement, though. Specifically the ".git/branches/name" mechanism was never removed as it had one distinct advantage over all other mechanisms for users who have to juggle tons of remotes that change either their URLs or branch names or both not so infrequently. Instead of having to edit files in .git/remotes/*, being able to say $ ls .git/branches/*partialname* $ echo "$URL#$branch" >.git/branches/foo $ rm .git/brnaches/foo was powerful. Offhand I do not know if "git remote" command improved the usability aspect of newer mechanisms good enough to allow us to start using the verb "replace" here.
On Mon, Jan 06, 2025 at 07:42:25AM -0800, Junio C Hamano wrote: > Patrick Steinhardt <ps@pks.im> writes: > > > back when Git was in its infancy, remotes were configured via separate > > files in "branches/" (back in 2005). This mechanism was replaced later > > that year with the "remotes/" directory. These mechanism have evenutally > > been replaced by config-based remotes,... > > Just a historical note, as I am not sure how much of it still > matters. In all of the above "replaced" is an incorrect verb to > use. "A more-powerful-but-different mechanism to do the same and > more was introduced later" is a fair statement, though. > > Specifically the ".git/branches/name" mechanism was never removed as > it had one distinct advantage over all other mechanisms for users > who have to juggle tons of remotes that change either their URLs or > branch names or both not so infrequently. Instead of having to edit > files in .git/remotes/*, being able to say > > $ ls .git/branches/*partialname* > $ echo "$URL#$branch" >.git/branches/foo > $ rm .git/brnaches/foo > > was powerful. Offhand I do not know if "git remote" command > improved the usability aspect of newer mechanisms good enough > to allow us to start using the verb "replace" here. I would claim the fact that nobody nowadays knows about either of the old mechanisms is a good indicator that git-remote(1) has indeed completely replaced them. I'm happy to slightly reword it though, even if it doesn't ultimately end up in any of the commits anyway :) Patrick
Patrick Steinhardt <ps@pks.im> writes: >> Specifically the ".git/branches/name" mechanism was never removed as >> it had one distinct advantage over all other mechanisms for users >> who have to juggle tons of remotes that change either their URLs or >> branch names or both not so infrequently. Instead of having to edit >> files in .git/remotes/*, being able to say >> >> $ ls .git/branches/*partialname* >> $ echo "$URL#$branch" >.git/branches/foo >> $ rm .git/brnaches/foo >> >> was powerful. Offhand I do not know if "git remote" command >> improved the usability aspect of newer mechanisms good enough >> to allow us to start using the verb "replace" here. > > I would claim the fact that nobody nowadays knows about either of the > old mechanisms is a good indicator that git-remote(1) has indeed > completely replaced them. I'm happy to slightly reword it though, even > if it doesn't ultimately end up in any of the commits anyway :) We can claim whatever, but scripts written in ancient days may still know about them and they do not care what we claim. And that is the primary thing that makes me worried. As suggested elsewhere, I think it is prudent to add some checks when remote.c notices that we used the values that were read via these old mechanims and complain loudly. Thanks.
Hi, back when Git was in its infancy, remotes were configured via separate files in "branches/" (back in 2005). This mechanism was replaced later that year with the "remotes/" directory. These mechanism have evenutally been replaced by config-based remotes, and it is very unlikely that anybody still uses these directories to configure their remotes. Both of these directories have been marked as deprecated, one in 2005 and the other one in 2011. This patch series follows through with the deprecation of these and announces them for removal in Git 3.0. Furthermore, it creates the infra to compile Git with such breaking changes enabled and wires up a CI job both for GitHub and GitLab to test those breaking changes. The series is based on top caacdb5dfd (The fifteenth batch, 2024-12-10) with ps/build at 904339edbd (Introduce support for the Meson build system, 2024-12-06) merged into it. Changes in v2: - Some small fixes to the deprecation notice of "branches/" and "remotes/". - Some small fixes to commit messages. - Link to v1: https://lore.kernel.org/r/20241211-pks-remote-branches-deprecation-v1-0-1431e2369135@pks.im Thanks! Patrick --- Patrick Steinhardt (5): Makefile: wire up build option for deprecated features ci: merge linux-gcc-default into linux-gcc ci: repurpose "linux-gcc" job for deprecations builtin/pack-redundant: remove subcommand with breaking changes remote: announce removal of "branches/" and "remotes/" .github/workflows/main.yml | 6 +---- .gitlab-ci.yml | 6 +---- Documentation/BreakingChanges.txt | 25 ++++++++++++++++++ Documentation/gitrepository-layout.txt | 7 +++-- GIT-BUILD-OPTIONS.in | 1 + Makefile | 7 +++++ builtin/remote.c | 2 ++ ci/lib.sh | 5 ---- ci/run-build-and-tests.sh | 3 ++- contrib/buildsystems/CMakeLists.txt | 1 + git.c | 2 ++ meson.build | 6 +++++ meson_options.txt | 2 ++ remote.c | 6 +++++ remote.h | 2 ++ t/t5323-pack-redundant.sh | 6 +++++ t/t5505-remote.sh | 6 ++--- t/t5510-fetch.sh | 13 ++++------ t/t5515-fetch-merge-logic.sh | 47 ++++++++++++++++++---------------- t/t5516-fetch-push.sh | 14 +++++----- t/test-lib.sh | 4 +++ 21 files changed, 112 insertions(+), 59 deletions(-) Range-diff versus v1: 1: 51bc2fc09e ! 1: c15229fb98 Makefile: wire up build option for deprecated features @@ Commit message breaking changes in the Git project. In 2454970930 (BreakingChanges: early adopter option, 2024-10-11) we have amended the document a bit to mention that any introduced breaking changes must be accompanied by - logic that allows us to easily enable the breaking change at runtime. + logic that allows us to enable the breaking change at compile-time. While we already have two breaking changes lined up, neither of them has such a switch because they predate those instructions. 2: 71dc627473 = 2: 0131ac856f ci: merge linux-gcc-default into linux-gcc 3: 8134955d0b = 3: 38a71377c0 ci: repurpose "linux-gcc" job for deprecations 4: aa986122ea = 4: a8d18e3499 builtin/pack-redundant: remove subcommand with breaking changes 5: b528488559 ! 5: 7445f06776 remote: announce removal of "branches/" and "remotes/" @@ Commit message Back when Git was in its infancy, remotes were configured via separate files in "branches/" (back in 2005). This mechanism was replaced later - that year with the "remotes/" directory. These mechanism have evenutally + that year with the "remotes/" directory. These mechanism have eventually been replaced by config-based remotes, and it is very unlikely that anybody still uses these directories to configure their remotes. @@ Documentation/BreakingChanges.txt: Cf. <xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.c ++ +As our documentation mentions, these directories are not to be found in modern +repositories at all and most users aren't even aware of these mechanisms. They -+have been deprecated for almost 20 years and 14 years respectively, and I am ++have been deprecated for almost 20 years and 14 years respectively, and we are +not aware of any reason why anybody would want to use these mechanisms. -+Furthermore, the ".git/branches/" directory is noadays misleadingly named and ++Furthermore, the ".git/branches/" directory is nowadays misleadingly named and +may cause confusion as "branches" are almost exclusively used in the context of +references. ++ --- base-commit: 713ec79a9091cec60b110d605b418904759982ab change-id: 20241205-pks-remote-branches-deprecation-037a4389a377