On Wed, 31 Oct 2007, Alejandro Martinez Ruiz wrote:There is only one undo command, and that one we've had since day 1: git reset --hard <state-you-want-to-go-back-to> will happily undo anything at all (including an earlier undo, apart from uncommitted dirty tree state, which is gone, gone, gone after that "undo" and can not be retrieved). That's the only real true "undo" with clear semantics - it actually does undo the whole history. But the kind of "undo" you wish for is not really possible. It implies a level of semantics that the system just doesn't know or care about. It also implies that anything else than the shape of history would matter for merging, which is just anathema to everything that makes git good in the first place. That said, in practice, this really seldom does come up. You can often use "git revert" as that kind of undo, and when you later do the merge, and the other side has fixed up the code, it's (a) likely going to be obvious in the conflicts and (b) if the fixes were to infrastructure and you had no conflicts, it's really easy to just revert the revert too! Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg Kroah-Hartman | [PATCH 006/196] Chinese: add translation of oops-tracing.txt |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Eric W. Biederman | [PATCH] nfs lockd reclaimer: Convert to kthread API |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
