git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Now What?

From
Junio C Hamano <junkio@cox.net>
Date
Nov 3, 2005, 18:38 UTC
Message-ID
<7vu0eth90o.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.64.0511030926020.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And that's exactly what "git reset --hard" is there for. It will reset to 
> the old head of the branch you are on (ie HEAD), and get rid of everything 
> that was done to the tree.

OK, then let's rewrite the procedure using 'reset --hard'. Then we do not have to use 'checkout -f' afterwards. The advantage of this approach is that 'reset --hard' would remove the new files the failed merge might have left in your working tree, while using 'checkout -f' would.

What now? Depends on what you wanted to do. If what you wanted to do was to merge my "master" to your "maint", then you would resolve the conflicts by hand, but probably that was not what you wanted to do.

After that pull, your repository is in this state:
. the index file and working tree is somewhere between your
  "maint" and my "master".  "somewhere between" is because the
  merge obviously failed.
. the "maint" head has not moved.  Your .git/HEAD points at the
  "maint" branch.
. the "origin" head points at my latest "master" head.

First thing is to bring your tree to a known state, to make recovery easier.

	$ git reset --hard

would match your working tree to your .git/HEAD, i.e. your "maint".

If you keep a copy of my "master" plus zero or more of your own development in your "master" branch, and what you wanted to do was to build my "master" plus those developments of your own, then:

	$ git checkout master
        $ git pull . origin

If your "master" is just a vanilla copy of my "master", then this pull would result in a fast forward, and "master" and "origin" will point at the same commit after this pull operation. Otherwise, you would merge your changes and my "master" updates into your "master" branch.

If what you wanted to do was to build my "master" vanilla, then:
	$ git checkout origin

because your remotes/origin says "origin" is meant to be a straight copy of my "master".

A good habit to get into is, before pulling, make sure:
. your index matches your HEAD.
. the local modification (i.e. what git-diff-files would report)
  is something you do not mind losing.
. you are on the right branch you want to pull into (check with
  "git branch").
Previous: Linus TorvaldsNext: Peter Eriksen
Message 10 of 20 in “Now What?”
  1. Jon LoeligerNov 3, 2005
  2. Chris ShoemakerNov 3, 2005
  3. Junio C HamanoNov 3, 2005
  4. Jon LoeligerNov 3, 2005
  5. Junio C HamanoNov 6, 2005
  6. Peter EriksenNov 3, 2005
  7. Junio C HamanoNov 3, 2005
  8. Daniel BarkalowNov 3, 2005
  9. Linus TorvaldsNov 3, 2005
  10. Junio C HamanoNov 3, 2005
  11. Peter EriksenNov 3, 2005
  12. Junio C HamanoNov 3, 2005
  13. Josef WeidendorferNov 3, 2005
  14. Daniel BarkalowNov 4, 2005
  15. Linus TorvaldsNov 3, 2005
  16. Junio C HamanoNov 3, 2005
  17. Junio C HamanoNov 3, 2005
  18. Josef WeidendorferNov 3, 2005
  19. Junio C HamanoNov 3, 2005
  20. Josef WeidendorferNov 3, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.