0

Git for Windows 2.5.2. I expect that if the index has the uncommited changes, then Git will disable the checking to other branches. But I see other result. Script of the sample:

#!/bin/bash
# script.sh
# Run this script in the Git Bash.
git --version
host="./sandbox"
if [ -d $host ]; then
    rm -r $host
    mkdir $host
    echo \"$host\" directory recreated...   
else
    mkdir $host
    echo $host directory \"$host\" created.
fi
cd $host
git init -q
touch 1.txt 2.txt 3.txt
git add "*"
git commit -qm "Initializing"
git branch
ls
git checkout -qb branch#1
rm 3.txt
echo ABCD >> 1.txt
# git commit -aqm "branch#1_commit#1"
git branch
ls
git checkout -q master
git branch
ls
git checkout -qb branch#2
rm 2.txt
echo 1234 >> 1.txt
# git commit -aqm "branch#2_commit#1"
git branch
ls
git checkout -q master
git branch
ls

I have such output:

bushm@DESKTOP-ISD2NUH MINGW64 /d/src
$ /d/src/script.sh
git version 2.5.0.windows.1
./sandbox directory "./sandbox" created.
* master
1.txt  2.txt  3.txt
* branch#1
  master
1.txt  2.txt
  branch#1
* master
1.txt  2.txt
  branch#1
* branch#2
  master
1.txt
  branch#1
  branch#2
* master
1.txt

bushm@DESKTOP-ISD2NUH MINGW64 /d/src
$

I see the swithing done but the working tree is the same (one file instead of three) after the switching (is not updated). I expected that after the switching of the index its contents will be nullified and branch's last commit will be extracted into the working tree. Why working tree was not updated according the content of the last commit of the master branch?

Andrey Bushman
  • 11,712
  • 17
  • 87
  • 182

1 Answers1

6

I expect that if the index has the uncommited changes, then Git will disable the checking to other branches.

That expectation is wrong. What you can expect is that if switching to a different branch might cause you to lose data, then Git will prevent you from switching to that different branch (unless you force it). But in your case, switching to a different branch doesn't cause you any harm. You have local changes to some files, but those files are the same in all of your branches, so the local changes can simply be kept.

  • >but those files are the same in all of your branches.
    Are you sure? I didn't delete files in the master branch. But why the working directory has two files still instead of three when I switch to master?     – Andrey Bushman Sep 15 '15 at 14:39
  • @Bush You didn't delete the files in any branch. The file deletions were only local changes that you never committed. Those local changes were preserved when you switched branches. –  Sep 15 '15 at 14:53
  • Missprint: one instead of two. – Andrey Bushman Sep 15 '15 at 14:53
  • I don't understand still. When I switch to other branch I expect the working tree will be changed also. Last commit of the master branch contains three files. But when I do `git checkout master`, the working directory has 1.txt only still. Why? – Andrey Bushman Sep 15 '15 at 16:30
  • 1
    @Bush Again, you removing 2.txt and 3.txt is a *local* change. It isn't part of the branch you came from. Because it's not part of the branch you came from, Git won't undo it behind your back, it keeps your local change of removing 2.txt and 3.txt. –  Sep 15 '15 at 17:11
  • The `master` branch has 1.txt, 2.txt, and 3.txt files. So, 2.txt and 3.txt are the part of the branch I came from. I expected that after the switching of the index its contents will be nullified and branch's last commit will be extracted into the working tree. – Andrey Bushman Sep 15 '15 at 17:20
  • @Bush And that expectation is still wrong. Git did not change since you asked your question. Your local changes don't get reverted by switching between branches. If you want to revert your local changes, use one of the commands to revert your local changes. `git checkout ` is not that command nor is it designed to be. –  Sep 15 '15 at 17:22