Search code examples
gitbranchgit-remote

git: checking out from remote branch changes local files?

I just checked out to a remote branch to see the differences with the local one directly in the files. Didn't make any change at all, but when I try to come back (ck = checkout) to the master, I get the error: "Your local changes to the following files would be overwritten by checkout: checkout from remote branch

Edit: the error doesn't say anything about pending commits or anything it just says abort

I don't get why a checkout would make any change to files, but the fact that the checkout is from a remote branch and the error says "local files" befuddles me... The local files then have to refer to the local master branch I'm switching to, but I have just committed all changes in that master branch... (!?). add . local master commit

Edit: this is the status right after the commit: enter image description here

What is that I (definitively) don't understand?

Solution

  • Short Answer

    Discard any changes to your work tree and that may have been added to the index with

    git checkout HEAD -- .

    For a repository on a Windows FAT32 filesystem, tell git to ignore the execute bits on file modes.

    git config core.fileMode false

    after which you should be able to checkout your master branch.

    git checkout master

    or using your alias

    git ck master

    Detailed Explanation

    After you tell git to add all new files and changes in the current directory (.) and in any child directories

    git add .

    and then commit, notice that git tells you the file permissions changed, e.g.,

    mode change 100644 => 100755 .gitignore

    Combined with the line immediately above it

    264 files changed, 0 insertions(+), 0 deletions(-)

    we conclude that the contents did not change — only the permissions.

    Context is critical for this paragraph. Immediately after you ran git commit -m 'many changes were not ...', you could have confirmed this by running git diff origin/master, and the output will consist of many sequences of the form

    $ git diff origin/master
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
[...]

    but with no new lines inserted or lines deleted.

    The appearance of your screenshots and a directory named Desktop lead me to believe (which your later comment confirmed) that you are using Microsoft Windows on a filesystem that does not represent the execute-mode bits, so git must be told to ignore it with git config core.fileMode false, which the git config documentation explains.

    core.fileMode
    Tells Git if the executable bit of files in the working tree is to be honored.

    Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out a non-executable file with executable bit on. git-clone or git-init probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.

    A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index.

    Git Philosophy

    Git is exceedingly careful not to destroy your work. Before it proceeds with the checkout of master, git compares the state of your present work tree with the head of your desired branch and, for example, sees that .gitignore as it sits differs from .gitignore in master.

    Because git sees uncommitted changes that it would have to overwrite to checkout master, it aborts the checkout and lets you know that you either need to throw away those changes intentionally

    git checkout HEAD -- .

    or put them somewhere for safe keeping with git stash or git add followed by git commit. With a clean work tree, you can then safely check out different branches.

    Comparing Files

    For details about what exactly has changed, run one of the commands below. The correct invocation depends on context.

    After Creating Your New Commit

    You added the changes and created a commit on branch master with SHA-1 object name 644ccb8 (as seen in your screenshot of the output from git commit -m [...]). At the time you created it, 644ccb8 became the HEAD of your master branch, and to see all changes between it and master out on origin, run

    git diff origin/master

    In English, this means “Show me all the changes between origin/master and the tip of the branch I am currently working on.” In fact, the command above is equivalent to git diff HEAD origin/master, which explicitly calls for a comparison against HEAD.

    To show the changes for one or more files named after a -- separator, use

    git diff origin/master -- .gitignore README.md

    After Staging But Before Committing

    Your screenshots do not show everything, but the text in green from the output of git status means that certain changes have been “staged” or added to the index. In git, we incrementally build up the next commit in the index (also referred to as the staging area or cache) with one or more invocations of git add and, less commonly, remove changes from the index with git reset. Once the index is in good shape, git commit adds a new commit with the contents of the index to the history.

    Your screenshots show that you ran git add . from your repository’s root.

    • Aside: Be aware that git add . paints with a broad brush. Sometimes that is what you want, but often it picks up more files than you intend — particularly when your .gitignore is missing a few patterns. After a big git add, always be sure to run git status to be sure you didn’t pick up any hitchhikers.

    After running git add one or more times but before running git commit, to see the changes currently in the index or cache, add the --cached option.

    git diff --cached

    or to limit to one or more specific files

    git diff --cached -- README.md

    Before Staging

    To see the delta between what is in your work tree and what is in the index (or cache), run one of

    git diff
git diff -- README.md

    This is the default mode of git diff.

    Detached HEAD

    Note from your screen capture that your repository has a detached HEAD, defined in the documentation as

    It means simply that HEAD refers to a specific commit, as opposed to referring to a named branch.

    As a rule of thumb, you generally do not want to checkout remote tracking branches (e.g., origin/master), tags, or SHA-1 hashes directly if you plan to make modifications.