"Git Add" Returning "Fatal: Outside Repository" Error

git add returning fatal: outside repository error

First in the clone folder you can create a Branch (so the master stay untouched)

git branch [branch_name]

After, just copy the files you want from your old folder to the clone folder.

When you are done, just add / commit your change and Merge your branch into the "master" branch. It will look like to something like this:

git add .
git commit -m "Comments"
git checkout master
git merge [new_branch]

Try this tutorial from GitHub.

Git add on repository sub directory returning 'fatal: [FOLDER] is outside repository'

So the answer turned out to be that I was using an absolute path when doing git add /path/to/folder/* instead of cd /path/to/folder/;git add *;

For some reason git didnt like the absolute path and was choking on it. Thanks for the help everyone!

git cached file is outside repository

You accidentally created a file called ~ inside your git project, and are now confused by the fact that you think the ~ refers to your home directory.

To delete this file, just quote the path:

git rm --cached "~/.config"

Git: How to add an external folder (of files) into an existing repository?

This sort of thing is outside the design of Git. I don't really want to close this as a duplicate of git: How do you add an external directory to the repository? for several reasons:

  • the person who asked that never accepted any of the answers;
  • the person who owns that question isn't on StackOverflow any more; and
  • none of the existing answers there really addresses all the issues.

When I mention the "design of Git" here, what I really mean is this: a Git repository is a collection of commits, where each commit is a full snapshot of some set of files. That set-of-files all must live (and coexist) within what Git calls a working tree or work-tree.

Besides the working tree, there is also a "git dir". This is where Git's own files—which store the repository contents—are located. By default, the Git directory is in .git in the top level of the working tree.

Hence, if the location of the working tree, in your particular repository, is /Desktop, the Git directory is /Desktop/.git, and vice versa. Since your Git directory is the latter, your working tree is the former. That means every file stored in each commit is always relative to /Desktop: a file named /dir/sub/file.ext—or dir/sub/file.ext; these are interchangeable in Git, and note that there are no folders or directories involved, just forward slashes—is stored in your working tree as the file named file.ext in the folder named sub in the folder named dir in /Desktop.

In other words, Git takes the file's path—complete with embedded forward slashes—and breaks it up into components, such as dir, sub, and file.ext. It then will make the folder dir/sub if needed, making the folder dir if needed. All of this happens in your chosen worktree path. Finally, once necessary folders exist, Git will create file.ext in the right folder, in your chosen worktree path.

This is all based on what's in the commits. The commits themselves are stored in a special, read-only, Git-only, format. Each file within a commit is stored in a Git-only format—not your computer's format, which uses files within folders—in which each file is further compressed and, to save space, de-duplicated across every commit. That means that if some large file is in 10,000 commits, but is the same in all ten thousand commits, there's really only one copy of that file in the repository, in Git's own internal compressed and de-duplicated format. The file's data is stored under a blob hash ID name, which your computer doesn't understand. The file's name is stored as more data, also compressed and de-duplicated!

The file itself is later de-compressed and turned into an ordinary file, and given a name that your computer OS understands, and put into your working tree; only then can you actually work with your file. That's one file from one commit, and it will reside in your working tree, coexisting with every other file from that same commit, also residing in your working tree.1


1Git has the ability to perform what Git calls a sparse checkout, where not every file is copied into your working tree, but this gets rather complicated.



The core.worktree trick in the other question

Git has the ability to separate the Git directory and the working tree. There are multiple ways to do this:

  • git --git-dir=path-to-.git --work-tree=path-to-working-tree command args ...
  • GIT_DIR=path-to.git GIT_WORK_TREE=path-to-working-tree command args ...
  • git config core.worktree path-to-working-tree

and so on.

If and when you use these various options, you have to be careful of, and aware of, various caveats. For instance:

  • The --git-dir and --work-tree arguments set the environment variables. (This avoids the stumbling block in the next bullet item.)
  • The environment variable setting depends on your shell: not every shell uses this particular syntax. Note that any env-var setting here may be overridden by a sub-process; the --git-dir and --work-tree arguments do this, for instance.
  • If you do separate the Git directory and work-tree, make sure the Git directory is not inside the chosen working tree. If it is, it may be seen as a submodule.
  • Commands, including hooks, that run within these may accidentally import or fail to import these environment variables at times they should not (e.g., working inside a different work-tree) or should (e.g., during execution of a hook). This may cause those commands to misfire. You'll need to be able to diagnose these situations and make corrections as necessary.

Overall, this can be made to work: you just need to be prepared for surprises. Because of the potential for surprises, I'd recommend always avoiding setting either the Git directory or the working tree to any location you cannot easily restore from some alternate copy or backup copy.

Receiving fatal: Not a git repository when attempting to remote add a Git repo

Did you init a local Git repository, into which this remote is supposed to be added?

Does your local directory have a .git folder?

Try git init.

Not able to add files to Git repository

It's not an empty folder. It is a submodule.

An empty folder would be irrelevant, because Git stores only files, not folders. A file's path name may be something like dir/file.ext. That's not a folder dir containing file.ext, but rather, just a file whose name is dir/file.ext. If your OS insists on storing such a file as a folder named dir containing a file named file.ext when you need to work on/with it, well, that's OK: Git will create a new empty dir folder and write into it a file named file.ext when necessary, during git checkout for instance. But Git has simply stored the file dir/file.ext. It has not stored dir.

But in this case, if you look more closely at ConnectorApp/, including looking for normally-hidden files and directories/folders, you will see that there is a ConnectorApp/.git. In other words, ConnectorApp/ itself is its own Git repository. A Git repository cannot contain another Git repository,1 so instead, your Git repository here will record that second Git repository as what Git calls, internally, a gitlink.

The mechanism behind a gitlink is that your Git can invoke a second sub-Git on your own machine, to enter the sub-repository—which Git calls a submodule—and ask it: Which commit is this repository using? The answer, if there is an answer, will be a raw commit hash ID.

The outer repository—which Git calls the superproject—then records, in each commit, this raw hash ID. Running git add ConnectorApp or git add ConnectorApp/2 tells your superproject Git to enter the submodule just long enough to find out the right hash ID and store/update it, as a gitlink entry.

The error message tells you that right now, the submodule—the other Git—does not have any commit checked out. So the superproject Git invokes the submodule Git and asks it which commit do you have checked out? and the submodule Git says get the ____ out of here, I don't have any!

To fix the problem, you have several options:

  1. Don't use submodules. Don't try to add ConnectorApp/ at all. Have your superproject be a Git without a submodule, and list ConnectorApp/ in .gitignore in the superproject so that it doesn't try to add it.

    This option only works if the superproject doesn't already list ConnectorApp as a submodule.

  2. Enter the submodule yourself, and pick out a commit. That is:

    cd ConnectorApp/
    git checkout <something>
    cd .. # return to superproject

    What you fill in for the something here determines which commit hash ID the superproject Git will see when the superproject Git asks the submodule Git which commit hash ID do you have checked out?

    This is how your superproject commit can record the correct commit to be used in the submodule.

  3. If your superproject Git has an existing recorded correct commit, you can have the superproject Git tell the submodule Git to check out the recorded commit:

    git submodule update --checkout

    (actually --checkout is the default, so you can typically omit it, but there are configuration items that can change this).

    Note that this applies to every submodule listed in the superproject. If there is only the one submodule, that's OK.

(Note that you can have improperly created submodules, where the superproject has a gitlink without the rest of the information required. This is probably not the case here, but it does happen sometimes. If it has happened, search StackOverflow for answers about that.)


1There's no technical reason that one repository could not contain another one wholesale, but there are administrative reasons not to do that, so Git is programmed not to do that.

2In the bad old days, git add ConnectorApp/ would go ahead and add all the files from the submodule to the superproject. This behavior is fixed now, which makes submodules much more workable than they used to be. If you have an old Git, though, be careful: don't let that trailing slash in there! I still have some burn scars from Git 1.5 or 1.6 days here.

VSCode: git fatal error: file is outside directory

If you use ASCII / Special chars (like æøå) in your path name this error occurs. Rename your path names / directories to the fix issue.

Be aware all parent paths for your projects directory needs to be changed, not just your paths / directories within your project.

Why is git add adding C:/Program Files/Git/ in front of a given path starting with / ?

Try

git add vendor/

Or, You can also add all the files using

git add .


Related Topics



Leave a reply



Submit