Hi guys,
Correct me if I'm wrong:
git-checkout saves the changes to index and working-tree, and
tries to apply them to the destined commit.
If the changes are applicable, then git-checkout the destined
commit and apply the changes.
Otherwise, git-checkout fails with warnings and leaves the current
status untouched.
If the above correct. Please help me clarify if the following corner
case an intended or unexpected behavior.
Setup and git repo with two commits to illustrate the scenario:
$ git init
$ echo aaa >> aaa.txt
$ echo bbb >> bbb.txt
$ git add .
$ git commit -a -m commit1
$ echo bbb >> bbb.txt
$ echo aaa >> aaa.txt
$ git commit -a -m commit2
Forge a unclean index with changes that are subset of the destined
commit we are about to switching to.
$ git checkout -b br1
$ git reset HEAD^
Unstaged changes after reset:
M aaa.txt
M bbb.txt
$ git checkout HEAD aaa.txt
$ git status --short
M bbb.txt
$ git add bbb.txt
$ git status
# On branch br1
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bbb.txt
#
$ git checkout master
Switched to branch 'master'
git silently switch to master without warning against the index are
"RESTORE/RESET" to clean.
$ git checkout br1
$ git status
# On branch br1
nothing to commit (working directory clean)
Is this an intended behavior?
Though the status and changes can be safely restore from the database
with some manipulation.
But it may become difficult and tedious if the number of involved
files are large.
Regards,
Roy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html