"Geoff Russell" <geoffrey.russell@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
