-1

I have a problem similar to this question BUT this is not a duplicate since the problem is different.

In that question, there was the problem of filenames too long for windows. The answer provided was to apply git config core.longpaths true

My own personal problem is that I have started cloning a repository. *In the middle of * clonning it stopped due to the filename too large error.

I tried

git config --system core.longpaths true

error: could not lock config file C:/Program Files/Git/etc/gitconfig: Permission denied

In the answer it says that it is better to not apply this globally so I did

git config core.longpaths true
fatal: not in a git directory

Ok I cd into the folder with the repo and I did the above and no problem. It is set. But an interrupted clone can not be continued so if I erase the folder the config set would dissapear too right?

So how can I do the git clonning without this problem?

KansaiRobot
  • 7,564
  • 11
  • 71
  • 150
  • 1
    Nearly never, you change `--system` git config. You should set your user config with `--global`... – Philippe May 11 '23 at 12:30

1 Answers1

2

Set it temporarily with --global, and then unset it when the repo is cloned, and then set it locally to the repo?

You can also initialize an empty repository, set the thing locally, add a remote and finally fetch that remote, something like:

$ mkdir my_repo
$ cd my_repo
$ git init
$ git config core.longpaths true
$ git remote add origin https://github.com/repo/whatever.git
$ git fetch origin
Andreas Louv
  • 46,145
  • 13
  • 104
  • 123
  • 2
    [`-c` can be used to set config options for a single command](https://stackoverflow.com/questions/15884180/how-do-i-override-git-configuration-options-by-command-line-parameters), so `git -c core.longpaths=true clone ...` should work. You'd probably still want to set that configuration in the newly created repository after that, though. – Joachim Sauer May 11 '23 at 08:58
  • @JoachimSauer Didn't know that, thanks for the information. Then the flow would be: `git clone -c core.longpaths=true ...`, followed by `cd repo` and finally adding the config locally: `git config core.longpaths true`. – Andreas Louv May 11 '23 at 09:00
  • 2
    @JoachimSauer Seems like it can go both places and have since git-1.7.7 https://github.com/git/git/commit/84054f79de35015fc92f73ec4780102dd820e452 – Andreas Louv May 11 '23 at 10:18
  • Interesting! I only tried it with `git status` because I didn't want to clone something to test his, but it makes sense to explicitly add that to clone. In fact I assume the ability in clone predates the more general one which applies to all commands, since for clone there's more need. – Joachim Sauer May 11 '23 at 10:23
  • 2
    It came a bit before, possible for git-1.7.2: https://github.com/git/git/commit/8b1fa778676ae94f7a6d4113fa90947b548154dd – Andreas Louv May 11 '23 at 10:28