Why do I have changes not staged for commit after cloning a Git repository?

Question

I am doing a group project and I am cloning the repository from GitHub to my local computer. I want to change the branch but it's asking me to to add the files first by git add myrepository, but I also have to git commit.

I don't want the commit to show up for cloning.

Why should I need to commit when clone?

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   BudgetAmazon.sln
        modified:   obj/BudgetAmazon.csproj.nuget.dgspec.json
        modified:   obj/BudgetAmazon.csproj.nuget.g.props
        modified:   obj/Debug/net6.0/BudgetAmazon.GeneratedMSBuildEditorConfig.editorconfig
        modified:   obj/Debug/net6.0/BudgetAmazon.assets.cache
        modified:   obj/Debug/net6.0/BudgetAmazon.csproj.AssemblyReference.cache
        modified:   obj/project.assets.json
        modified:   obj/project.nuget.cache

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout add_to_cart
error: Your local changes to the following files would be overwritten by checkout:
        Server/BudgetAmazon/BudgetAmazon/BudgetAmazon.sln
        Server/BudgetAmazon/BudgetAmazon/obj/BudgetAmazon.csproj.nuget.dgspec.json
        Server/BudgetAmazon/BudgetAmazon/obj/BudgetAmazon.csproj.nuget.g.props
        Server/BudgetAmazon/BudgetAmazon/obj/Debug/net6.0/BudgetAmazon.GeneratedMSBuildEditorConfig.editorconfig
        Server/BudgetAmazon/BudgetAmazon/obj/Debug/net6.0/BudgetAmazon.assets.cache
        Server/BudgetAmazon/BudgetAmazon/obj/Debug/net6.0/BudgetAmazon.csproj.AssemblyReference.cache
        Server/BudgetAmazon/BudgetAmazon/obj/project.assets.json
        Server/BudgetAmazon/BudgetAmazon/obj/project.nuget.cache
Please commit your changes or stash them before you switch branches.

Answer 1

If you mean that you run, e.g.:

$ git clone https://github.com/git/git.git
Cloning into 'git'...
remote: Enumerating objects: 322336, done.
remote: Counting objects: 100% (1805/1805), done.
remote: Compressing objects: 100% (871/871), done.
remote: Total 322336 (delta 1161), reused 1380 (delta 932), pack-reused 320531
Receiving objects: 100% (322336/322336), 183.59 MiB | 4.20 MiB/s, done.
Resolving deltas: 100% (240649/240649), done.
$ cd git
$ git status

for instance, and this git status produces the kind of messages you're showing above, that tells us one or both of two things, which amount to "the source repository you're cloning is Evil":

• the repository you're cloning has files named a/b/c.ext and a/B/c.ext or a/b/C.EXT in it, and your system cannot handle this; and/or
• the repository you're cloning has, stored in it, files with literal CR-LF line endings, and you're on Windows and have configured core.autocrlf to true.

The amount of evil represented by these two bullet points is small:

• Mixed-case mixed-use files like this work just fine on Linux (typically), but (typically) not on Windows or macOS. So anyone who does this has set up Windows and macOS users for failure. Why did they do that? Presumably, because they are evil, or at least devilish imps. ?

• Git in general is not a substitute for file-format (storage format, including UTF-8 vs UTF-16, and line-ending-style) management. However, Git does have some minimal, barely-serviceable facilities for handling some of these issues. Some people use them misguidedly (evil by mistake), some people don't use them at all (not really evil at all but can result in a trap for you), and some people use them correctly (also not evil, and no trap for you as long as you set your system up correctly).

Which, if any, of these is the actual problem, I can't tell without access to the original repository (which I can then inspect on a Linux or similar system, which will show me what's really in it: viewing it on a Windows system, you'll see only the limited stuff that Windows can show you, unless you're a Git Expert).

Both generally require at least a little bit of cleanup of the original source repository. That's the repository at the site (github.com or wherever) that you used to get your clone. The problem is now in your clone too, because commits, once made, are entirely read-only, and your Git software copied all their commits so you have all of their problems. They probably are not problems for them, but they are problems for you. You can't force them to fix their problems. You thus have three choices:

• Ask / beg them to fix their problems. If they do, your problems after cloning vanish.

• Fix their problems for them. This can be difficult, especially if they're not interested in your fixes, but with co-operation, perhaps you can get their problems fixed and get them to take the fixes.

• Avoid their repository. Don't clone it in the first place, or—if you need it—clone it once, fix it up, and from that point on in time, never talk with them again.

Fixing the problem(s)

The first step is to identify the problems. Are they:

• Line endings? These are easier to fix; you can do this on a Windows system without any assistance. See VonC's answer to Distributing git configuration with the code for instance.

• File names? To fix these, the easiest way is to find or build yourself a Linux system. On Windows or MacOS, the easiest way to do that is with VirtualBox or other VM systems as powered by something like Vagrant. Using the Linux system, clone the repository there, rename the files appropriately, commit, and push the fixed commit(s)—you may need to fix multiple branch tip commits—back to wherever they will go.

Once you have a corrected repository—whether that's your own private one (a "fork" on GitHub or other hosting sites for instance), or the original if the owners of the original repository will fix it or let you fix it—you can clone it without trouble.