trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] TIME Frame 3/29 -> 4/10 kwrite crash introduced

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 30 Apr 2012 19:12:41 -0500
>> "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