Skip to content

Git fetch fails with too long branches since 2.48.1 #5476

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
JohnnyDoesStuff opened this issue Mar 10, 2025 · 3 comments · Fixed by #5550
Closed

Git fetch fails with too long branches since 2.48.1 #5476

JohnnyDoesStuff opened this issue Mar 10, 2025 · 3 comments · Fixed by #5550
Assignees
Milestone

Comments

@JohnnyDoesStuff
Copy link

Since git 2.48.1 i got issues when fetching long branches from a repository (usecase: The repository should be fetched by Jenkins, so path lengths get past 260 characters).

Steps to reproduce:

  1. Have a git repository with a branch that has a long name
  2. Create a directory with a very long name
  3. Open git in that directory
  4. git init
  5. git fetch --no-tags --force --progress --prune -- https://github.com/foo/bar.git +refs/heads/*:refs/remotes/origin/*

Expected result
Everything is fetched (When executing this with git 2.47.1 it works)

Actual Result
For the long branches i get these error messages:

error: couldn't set 'refs/remotes/origin/foo/loooooooooooooooong_branch_name'
! [new branch]          foo/loooooooooooooooong_branch_name -> origin/foo/loooooooooooooooong_branch_name  (unable to update local ref)
@jglick
Copy link

jglick commented Mar 10, 2025

A somewhat different issue (but also apparently a recent regression) is noted in jenkins-infra/helpdesk#4574 that does not involve particularly lengthy branch names or version paths or any other detail of the repository content: that if the path to the repo root is more than about 206 characters, the fetch fails just appending the length of a SHA (jenkins-infra/helpdesk#4574 (comment)):

error: unable to write file .git/objects/88/5d62fd3383b2b55160833372cd33968adc3a97: Invalid argument

@dduportal
Copy link

The bug is still present with 2.49.0: even with the Git configuratiion core.longPaths set to true AND the Kernel setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1, the problem is still present.

For the record, it stopped working with 2.48.1, despite the settings specified in https://github.com/git-for-windows/git/blob/main/Documentation/config/core.adoc

core.longpaths

Enable long path (> 260) support for builtin commands in Git for Windows. This is disabled by default, as long paths are not supported by Windows Explorer, cmd.exe and the Git for Windows tool chain (msys, bash, tcl, perl…​). Only enable this if you know what you’re doing and are prepared to live with a few quirks.

@dscho dscho added this to the Next release milestone Apr 7, 2025
@dscho dscho closed this as completed in 2cdc2d6 Apr 7, 2025
dscho added a commit that referenced this issue Apr 7, 2025
When rebasing c8b6c1d (mingw: support long paths, 2015-07-28) on
top of 391bcea (compat/mingw: support POSIX semantics for atomic
renames, 2024-10-27) a newly introduced MAX_PATH buffer was not
increased to MAX_LONG_PATH.

This fixes #5476
@dscho
Copy link
Member

dscho commented Apr 7, 2025

/add relnote bug Git for Windows 2.48.1 introduced a regression when fetching long branches under core.longPaths = true, which was fixed.

The workflow run was started

github-actions bot pushed a commit to git-for-windows/build-extra that referenced this issue Apr 7, 2025
[Git for Windows 2.48.1 introduced a
regression](git-for-windows/git#5476) when
fetching long branches under `core.longPaths = true`, which [was
fixed](git-for-windows/git#5550).

Signed-off-by: gitforwindowshelper[bot] <gitforwindowshelper-bot@users.noreply.github.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants