On Wed, 3 Dec 2008, Junio C Hamano wrote: > > I think a bit more explicit description with an example command sequence > in the documentation is in order. Here is what I managed to reconstruct > from your description. > > Let's say you have a small change in the Makefile and some other local > changes that you would want to keep uncommitted. Then you receive a > pull request that you would want to respond to. So you do this: > > $ git pull $URL $branch > > knowing that your own local changes will be safe because pull will > refuse to clobber them if the changes in the other person did overlaps > with it. Let's further say that the changes did not overlap, the > merge succeeded and you still have your own local changes. > > But after inspecting the result, you realize that you do not want this > change after all. That means rewinding the HEAD back to the previous > point (i.e. ORIG_HEAD), match the index to that commit, *and* rewind > the work tree back to the state before the merge (i.e. mostly matching > the index except for the local changes to Makefile and a handful other > files). "git reset" is the command to move the HEAD. What mode > should you use? > > Unfortunately, the only two modes that touch the index and/or the work > tree are --mixed and --hard. > > You do not want to use --hard, because it will discard your local > changes. You do not want to use --mixed either, because it will keep > not just your local changes but also the changes the merge brought > into your work tree. That's when you would want to use --merge mode. > > $ git reset --merge ORIG_HEAD Exactly. > The recovery procedure I would use in such a case (and I rarely pull while > managing git.git even though I do so in my day job) would be: > > $ git checkout -b this-needs-more-work > $ git checkout master No, that won't work. The second 'git checkout' does nothing, since 'master' still has all the broken code in it. It would have worked had you started the new branch _before_ the pull, but if you had that, then you wouldn't have had anything to reset anyway, you'd just switch back to master and get rid of the new temp-branch. But you could probably do something like this: git checkout -b temp-branch ORIG_HEAD git branch -M master which depends on that checkout doing the right thing. Linus -- 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
