Re: About detached heads

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 15, 2008, 00:03 UTC
Message-ID: <m3zlt0x39k.fsf@localhost.localdomain>
In-Reply-To: <93c3eada0803141643r2f2c4c56l9e59f2ee7b67a8ca@mail.gmail.com>

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

Show 13 quoted lines

> 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