30 Apr
2012
30 Apr
'12
11:34 p.m.
"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