"git
reset --soft" just moves HEAD. The index is unaffected, so
everything that has changed between your current position
and the point you reset to is now listed as a 'change to be committed'
in
'git status'.
"git reset --mixed" (the default) moves HEAD and wipes out
the index, but leaves the working tree unaffected.
"git reset --hard" wipes out the working tree, the index,
everything. It doesn't touch untracked files, though.
And, the most extreme, "git clean" wipes out untracked files
(possibly including ignored ones and whole unknown directories, see
the manpage).
This is a right terminological mess, I must admit.
I don't know how this is supposed to work. I ran 'git reset --hard'. When
I viewed the top level with git log, the newest date was April 10. Seemed
okay to me.
After my previous two builds and testing I wondered whether that truly
reset the source files. I changed to the tdebase directory and again ran
git log. The most recent commit was from a few days ago.
So I did a git reset there too and in tdelibs.
In light of this, I don't think my previous build runs and tests were
credible because more than likely I was building at least tdelibs and
tdebase with recent sources.
There must be a way to correctly reset my sources so I build with the
sources from that date and ignore all commits thereafter. I love wasting
my time.
Darrell
Try this:
git reset --hard HEAD
git checkout <hash>
That should do the trick!
Tim