Re: git-bisect is magical

On Tue, 10 Jan 2006, walt wrote:
> 
> Just by stumbling around and trying things at random, I did a
> 'git-checkout origin' which *seemed* to resolve the merge-conflict,
> but left me feeling uneasy because I don't really understand what
> I'm doing.  Can you give a short explanation of the difference
> between 'git reset --hard origin' and 'git-checkout origin'?

"git checkout" actually checks out a different branch (unless, to confuse 
things, you ask it to just check out a specific _file_, in which case it 
stays on the same branch).

So when you say "git checkout origin", it actually _switches_ to the 
origin branch (which is just my state) and checks that out.

When you then do a "git pull", you'll just be pulling my newer state into 
that older content branch, and it will resolve beautifully as a 
fast-forward with no merge at all.

The downside with being in the "origin" branch is that if you now do any 
kind of real development, you've now made "origin" mean something else 
than it traditionally means - now it's no longer a branch tracking the 
origin of your code, now it's an active development branch.

Do "git checkout master" to go back to where you used to be.

In contrast, a "git reset --hard origin" would have reset your _current_ 
branch to the state that the "origin" branch was in (and forced a checkout 
of that exact state too - that's what the "--hard" flag means).

So when you say "git checkout origin", you should read it as "check out 
the origin branch", and thus it makes perfect sense that "origin" now 
becomes your current branch. In contrast, when you say "git reset --hard 
origin", you should mentally read that as "reset the state of my current 
tree to the same state as the origin branch".

The naming does make sense, but you just have to get used to what 
"checkout" means (in its two different guises - checking out a file being 
different from checking out a full tree) and what "reset" means.

> > An even better option is obviously to figure out _why_ that commit broke 
> > for you in the first place, and get it fixed up-stream...
> 
> I'm still waiting for the insulting email from the developer ;o)  How
> long should I wait for a response before I start bugging other people?

Hey, send out the report to linux-kernel, and if it is a serious problem, 
just cc me and Andrew (and whoever else seems to be most relevant for the 
area: networking goes to David Miller, drivers mostly to Greg or Jeff etc 
etc). Regardless, you should always cc at least the people who signed off 
on the commit, since they want to know that they signed off on something 
that turned out to be buggy.

		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