"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