On Fri, 2009-04-17 at 22:54 -0500, William Hubbs wrote:
[...]
>  Here is my understanding of what rebase does.  Say that I'm working on
>  the master branch, and I do a commit, but someone else is also working
>  on the master branch at the same time.  They do a commit and push
>  before I do my push.
> 
> Now I try to push.  Git will complain because my master branch is not up
> to date.  If I do a git pull without --rebase at this point, I will
> create a merge in the history.  But, if I do a git pull --rebase, my
> local change, which has not been pushed yet, will be moved forward so
> that it happens after all of the changes I pull.  If there are
> conflicts, I resolve them on my end. then continue the rebase process
> until it is done.  Then I do a git push to push my change to the central
> repository.
> 
> My only question about this would be, what would happen if I do not
> resolve the conflicts correctly locally.

Just to expand on this, what happens is this. Assume the timelines of
the remote and local branches look like this:

remote: 1 -- 2 -- 3 -- 4 -- 5
local:  1 -- 2 -- 3 -- a -- b ('a' and 'b' are local commits)

You last sync'ed your tree at version '3', and want to rebase, so the
tree looks like:

local:  1 -- 2 --3 --4 -- 5 -- a -- b

What 'git rebase' does is that it rewinds the local tree back to '3',
pulls in revisions '4' and '5', then applies each local commit on this
tree. As each 'patch' is applied, if there is a conflict, the rebase
pauses and lets you resolve the conflict (you fix conflicting files and
then 'git add' them), and then you can tell git to continue the rebase.

In this sense, if you do not resolve a conflict correctly, it is about
the same as not resolving a conflict correctly during a 'git pull' --
your tree will be broken (or at least incorrect).

Hope this makes sense.

Cheers,
Arun