All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Bill Lear <rael@zopyra.com>
Cc: git@vger.kernel.org
Subject: Re: Git rescue mission
Date: Thu, 8 Feb 2007 09:27:50 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0702080858430.8424@woody.linux-foundation.org> (raw)
In-Reply-To: <17866.27739.701406.722074@lisa.zopyra.com>



On Wed, 7 Feb 2007, Bill Lear wrote:
> 
> I have a public bare repo on my machine that I have cloned to make a
> private repo.  I just want to sync my branches on my public and
> private repos.  I do not want to merge across branches, I just want to
> "sync".

Ok, others already replied, but here's a few rules to ease your mind in 
general:

 - First off: you can always _trivially_ get back to whatever state you 
   had before, as long as you committed it, and didn't have any dirty 
   state (uncommitted patches) in your working tree.

This is something that it's worth repeating, and even perhaps 
experimenting with to get really comfortable with. Why? Because once you 
learn to get back to any random state you had before, and once you are 
comfortable with that, you suddenly lose the fear of experimenting. 
Whatever you screw up, if you're confident you can get back, who cares?

So the "get back from a mistake" should probably be at the very front of 
our manuals and tutorials. I don't think it currently is, but it's 
actually not that hard. There's just one command to remember: "git reset", 
and the only issue you might ever have with it is:

 - make sure you're on the right branch first! If the problem you had is 
   that you're on the wrong branch, switch branches first! Don't try to 
   make the wrong branch "look right". But once you know you're on the 
   right branch, you know that "git reset" is your friend to getting it 
   anywhere you want.

 - do you want to throw away all your working tree changes (and if 
   you screwed up some git operation, the answer is usually "Yes!"). If 
   so, add the "--hard" flag. It's not on by default, exactly because it 
   *will* throw away all state in your tracked working tree, and reset it 
   to whatever you want to go back to.

 - exactly *what* do you want to go back to? The default is to go back to 
   the state at the last successful commit, but sometimes what you screwed 
   up was exactly the last commit (eg an unintentional "pull" that 
   actually succeeded), and then you need to tell it *what* to reset to.

That's really all there is to it. It's really simple, although especially 
the second point can take some practice to get right.

So NORMALLY, if you did something bad - say, you edited a file, and just 
realized that the whole edit was just crap, and you want to start over - 
you just do a simple

	git reset --hard

and it will just reset all your git state to the last commit you did. 

This is what you'd do in this case, when you had a "git pull" that simply 
*failed* due to conflicts, and you realize that you didn't do that merge 
at all.

However, what happens if you actually do a "git pull" that doesn't have 
any conflicts (or at least they merge fine), so the pull actually 
*succeeds*, but you realize that wasn't what you wanted to do at all?

In that case, you need to say

	git reset --hard <point-you-want-to-go-back-to>

to just reset to the previous state. Now we get to that "how do I figure 
out what state that was?" part of the question, and usually it's trivial 
to answer.

For example, a command like "git pull" will leave a special magic name 
around to tell you what the original HEAD was before the pull, and that 
magic name is (surprise surprise) called ORIG_HEAD. So if the pull 
succeeded, but you realized it was an error (perhaps you had even intended 
to do it, but once you pulled, you just saw that what you pulled was crap, 
so you decide that you didn't really want to do it after all), you can 
just do

	git reset --hard ORIG_HEAD

and you're back to where you were _before_ the pull.

It really is that easy. And once you get comfortable with it, and you 
really know deep down how easy it is, that should just relax you a lot. 
When you go "AIEE! I made a horrible mistake!" you should just laugh, and 
say "and I don't *care*, because I can just trivially undo it!".

Now, usually it's really as simple as just using ORIG_HEAD (or the 
top-of-the-branch itself when the pull simply failed), but you can 
actually do it for any commit. Say, you've worked for a week, and have 
committed five or six things (and you don't even quite remember), and you 
are just weary, and realize that IT IS ALL CRAP!

Now, before you just decide to drown your sorrows in a bottle (or, 
perhaps, the morning after), you realize that you haven't actually pushed 
it out to anybody else yet (because it wasn't ready anyway), and that you 
can just undo the whole thing!

So what do you do?

You just fire up gitk, or whatever your favourite history viewer is (git 
log, qgit, whatever), and you select the last good commit by hand, and do

	git reset --hard <selected-commit-sha1-name>

which you just cut-and-paste from your history viewer. And magic happens. 
It's all gone, and you're now at that old state in history, and all your 
crap is gone, gone, gone. You can now have a drink or five, happy in the 
knowledge that you just wasted five days of your life, but nobody will 
ever even know your dark dirty little secret, and hopefully you're getting 
paid by the hour, not by the end result anyway.

Of course, if you have reflogs enabled (see previous discussions), it's 
even easier. In particular, it's easier if you do a "git reset" to some 
other point in history, and suddenly realize that what you want to undo is 
really that "git reset" itself ;)

(Even if you undo things, that's also recoverable, as long as you haven't 
done any garbage collection. But it can be harder, because now you won't 
get "git log" or "gitk" to show the stuff you undid, so this is where 
reflogs can save your bacon, since they will remember the old stuff too. 
Without reflogs, you either need to have it in ORIG_HEAD, or you need to 
run "git fsck-objects" and look at all the dangling commits by hand).

So be happy. "git reset" can be dangerous (you *are* throwing things 
away), but it's also very powerful, and pretty easy to use. And git makes 
it fairly hard to *really* throw anything committed away, so even if you 
undo something, and realize you want to re-do it again, it's possible to 
go back - at most it's just a bit more involved to *find* the place to go 
back to.

One final (and unrelated) note. If all you want to do is "sync up", and 
not actually merge anything new into your current branch, you should just 
do "git fetch". Not "git pull". Doing a "pull" implies merging into your 
current branch, and thus does more than just "sync up" the branches you 
are tracking.

			Linus

  parent reply	other threads:[~2007-02-08 17:27 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08  0:18 Git rescue mission Bill Lear
2007-02-08  0:22 ` Johannes Schindelin
2007-02-08  0:24   ` Bill Lear
2007-02-08  0:25     ` Johannes Schindelin
2007-02-08  0:34       ` Bill Lear
2007-02-08  0:48 ` Junio C Hamano
2007-02-08  4:28   ` Alexander Litvinov
2007-02-09  0:53     ` Junio C Hamano
2007-02-09  3:32       ` Alexander Litvinov
2007-02-08 15:27   ` Bill Lear
2007-02-08 15:56     ` Jakub Narebski
2007-02-08 23:24     ` Jeff King
2007-02-08 23:32       ` Bill Lear
2007-02-08 17:27 ` Linus Torvalds [this message]
2007-02-08 20:12   ` Kalle Pokki
2007-02-08 21:23     ` Linus Torvalds
2007-02-08 22:03       ` Kalle Pokki
2007-02-08 22:10         ` Shawn O. Pearce
2007-02-09  1:48           ` Theodore Tso
2007-02-09  1:58             ` Shawn O. Pearce
2007-02-09  2:01             ` Jakub Narebski
2007-02-10 16:05             ` Theodore Ts'o
2007-02-10 16:05               ` [PATCH] Print a sane error message if an alias expands to an invalid git command Theodore Ts'o
2007-02-10 16:05                 ` [PATCH] Allow aliases to expand to shell commands Theodore Ts'o
2007-02-10 18:04                   ` Linus Torvalds
2007-02-10 18:13                   ` Theodore Tso
2007-02-10 20:34                     ` Johannes Schindelin
2007-02-11  0:13                       ` Theodore Tso
2007-02-11 16:03                         ` Johannes Schindelin
2007-02-11 16:21                           ` Theodore Tso
2007-02-11 16:36                             ` Johannes Schindelin
2007-02-11 21:44                             ` Junio C Hamano
2007-02-11 22:03                               ` Johannes Schindelin
2007-02-12  3:56                               ` Theodore Tso
2007-02-12  6:53                                 ` Shawn O. Pearce
2007-02-10 16:50                 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Junio C Hamano
2007-02-09 19:21           ` Git rescue mission Kalle Pokki
2007-02-08 21:57   ` Bill Lear
2007-02-08 22:13     ` Linus Torvalds
2007-02-08 22:33       ` Bill Lear
2007-02-08 23:25       ` Bill Lear
2007-02-08 23:33         ` Shawn O. Pearce
2007-02-08 23:40           ` Bill Lear
2007-02-08 23:50             ` Shawn O. Pearce
2007-02-09  0:03             ` Jakub Narebski
2007-02-09  0:17             ` Linus Torvalds
2007-02-09  8:58             ` Michael S. Tsirkin
2007-02-08 23:38         ` Jakub Narebski
2007-02-08 23:46         ` Linus Torvalds
2007-02-09  4:38       ` Junio C Hamano
2007-02-08 22:29     ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0702080858430.8424@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=rael@zopyra.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.