Re: About detached heads

"Geoff Russell" [off-list ref] writes:

I thought my question was trivial, but judging by the number of
answers, clearly not!

I understand "git read-tree -u -m 3 ; git commit" and it does exactly
what I want.

The context where I want to use this is for users who update files,
can understand "take me back to the state I was in at 4pm yesterday
before I mucked up my data" but who don't want to know about
merging, branching, topics, etc, etc, But of course having taken
them back to the 4pm commit, they then realise that they really need
the 6pm commit or perhaps the 3pm commit. So anything which just
throws away commits would be risky.

Thanks to the reflog even if they go the "git reset --hard 3" route,
the commits would be protected for gc.reflogExpireUnreachable period,
which defaults to 30 days, by reflog. After this period they could be
garbage-collected.

The "git read-tree -u -m 3; git commit" allows me to present a
simple straight line view of the data, which is perfect for the
people I'm dealing with.

Simple, straight line with _rewinds_, i.e. not so simple history.

Unless you can expect users to find errors later than 30 days, or you
have pushed non-rewritable branch already, then "git reset --hard 3"
is IMHO a beter solution than "git read-file -u -m 3 && git commit -a".

-- 
Jakub Narebski
Poland
ShadeHawk on #git