On 11/04/13 15:27, Gert Doering wrote: > Hi, > > On Thu, Apr 11, 2013 at 04:25:18PM +0300, Samuli Seppänen wrote: >> As long as nobody is actually using the staging repo rewriting history >> should not be an issue. Perhaps one could just do >> >> $ git reset --hard HEAD^1 >> $ git push origin master >> >> and be done with it?
Do not ever do that without fully understanding what it does. Basically it rewrites the git history, and others who have cloned this repo will get ugly warnings from git on the next git-fetch. Whenever such warnings appears, it can indicate that the git tree has been compromised. And if you have some merges involved and do this on a merge commit ... well, things gets even more complicated. This operation should only be done when no other alternatives will work. It is the last resort of a git fix. By all means, use git-reset, but avoid it once you've pushed out a commit you want to remove. If you use git-reset on a local un-pushed tree, that's all fine. That's called cleaning up before you push. But once pushed, rather clean it up differently. > Will that un-push already-pushed commits? Or just have "one commit less > than $remote" in your local repo? Yes, and it will make users of such a git tree become suspicious. I rather recommend using 'git revert' instead. Which simply reverts the commit, you add a reason why it was reverted ... and it's all logged as a new separate commit. Much cleaner, and it documents what we've tried and why we didn't use the patch after all. We don't need to be ashamed of pushing out things which breaks, as long as we fix it. -- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
