Re: About detached heads

[Jakub Narebski <jnareb@gmail.com>]

"Geoff Russell" <geoffrey.russell@gmail.com> 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