On Nov 19, 2007, at 5:45 PM, Lars Hjemli wrote:
On Nov 19, 2007 2:05 PM, Jonas Juselius
<jonas.juselius@xxxxxxxxxxx> wrote:
Also, I think you might scare users away from 'git reset':
git reset resets the branch to a specified state invisibly and
without possibility to go back. Ever. Your call.
That's not true, since any "modern" git has reflogs enabled. If you do
'git reset --hard HEAD^^^' and then realize it was a mistake you can
just 'git reset --hard HEAD@{1}'
Yes, I've always been very scared of git-reset until I had a somewhat better understanding of Git internals. In fact the only danger of `git reset --hard' is that you loose dirty changes (not yet in the index) and staged changes (in the index). git-reset will never, ever delete objects from your repo. Thus, you can perfectly well remember the current revision sha1 (let's call it `A') and then git reset -- hard HEAD~42 and then git reset --hard A. In between the two Git commands, it's possible that all the objects of the history from HEAD~42..A be unreachable. Nothing wrong with this, it just that if run, say, git gc --prune (note the --prune) you will loose them.
Understanding this is very important because ``error humanum est'', and people happen to screw up their hard work and they don't realize that they can go back without even knowing what the hell the reflog is or how to use it (I personally don't know -- but I'd like to, give me pointers please :D). For instance, I once rebased a dozen of commits on a given branch and I realised that I completely screwed my nice patch series by collapsing changes, introducing changes at the wrong revision etc. I could start over again by simply doing a git reset --hard <HEAD_sha1_before_rebase>.
Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
Attachment:
PGP.sig
Description: This is a digitally signed message part
