Ok. That makes some sense.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/JiwrQLfEtUYJ.
To post to this group, send email to git-users@googlegroups.co
Ah, good to know. Thanks.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/9azpXq6M47sJ.
To post to this group, send email to git-users@googlegroups.com
On Tue, 10 Jan 2012 14:47:44 -0800 (PST)
Trans wrote:
[...]
> My mistake was to use `--hard`, but I didn't think it would delete
> the files b/c there were not being tracked before this particular
> commit.
That is logical, just from the opposite point of view: you asked Git to
chop off the tip
We've all been there :)
You can also directly reset your current branch to point at the lost
commit, instead of making a branch for it:
$ git reset --hard shaOfResetCommit
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this d
How about "git add -u"?
from the docs:
-u, --update
Only match against already tracked files in the
index
rather than the working tree. That means that it will never stage
new files, but that it will stage modified new contents of
tracked
file
