The following was the status of my repo.
[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst
# On branch design
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# modified: _layouts/default.html
# deleted: _site/blog/2010/04/07/welcome-to-niraj-blog/index.html
# deleted: _site/blog/2010/04/08/the-code-syntax-highlight/index.html
# deleted: _site/blog/2010/05/01/showing-demo-to-kalyan/index.html
# deleted: _site/config.ru
# deleted: _site/index.html
# deleted: _site/static/css/style.css
# deleted: _site/static/css/syntax.css
# modified: static/css/style.css
no changes added to commit (use "git add" and/or "git commit -a")
git checkout -f
[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst
# On branch design
nothing to commit (working directory clean)
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔
I don't think you can recover those private data ("private" as in "not added in the index, nor committed", so unknown to git), unless you have other backup process in place for your current working directory.
Even if this is not proposed in the Git Aliases page, I would argue for some kind alias for checkout (like there is the
alias rm /bin/rm -i usage):
[alias] co = !sh -c 'git stash; git stash apply; git checkout "$*"'
This issue reminds me of a debate on this behavior on ycombinator (extracts):
I've lost plenty of data with git.
Most of it has to do with innocuous-sounding commands that don't ask for confirmation when deleting data.
git checkout filenameis equivalent to
svn revert filename.
git checkout branchnamedoes something completely different.
If a branch and a file share the same name, git will default to switching branches, but that doesn't stop bash autocomplete from ruining the day.
Here's a crazy idea: If you have an innocuous action and a dangerous action, do not label them with the same command.
Annoying, maybe, but this is user error, not design error. With git, if I want to losslessly discard my working copy, I can just "
By your logic, "rm" is flawed because it doesn't ask for confirmation when you pass
-i. Well, yeah. Sorry.
Your analogy would be more accurate if
rm somenamewas the equivalent of
apt-get update, and
rm -fr othername.
Still, it can't be right that "
get checkout foo" does one of two COMPLETELY different things depending on whether or not there is a file called foo in the current directory
Here's another crazy idea: don't run '
git checkout ...' on a dirty work tree. Problem solved.
Another one: don't reuse filenames as branch-names.
To be honest: I have the same problem with careless invocations of '
rm' ruining my day but when I'm muttering curses it is at my lazyness/stupidity and not at bash completions or the behavior of '