On 8/13/14 7:16 AM, Sergey Organov wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> 3. Merge conflicts, if any, as well as their resolution, are very
>>>    similar in both workflows. The only difference is that one needs to
>>>    learn to use "git rebase --continue" instead of "git commit" after
>>>    conflicts are resolved.
>>
>> …whereas for rebase, some of the state is stashed away in the .git
>> directory (hence the need to use "git rebase --continue" which fetches
>> the leftover state and keeps on processing it).
>>
>> It definitely takes some getting used it.
> 
> Yes, indeed, it's unnatural to use "git rebase --continue" to continue
> interrupted "git pull".

To git's credit, it at least prints that arcana out when you need it:

    $ git pull --rebase ../b
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From ../b
     * branch            HEAD       -> FETCH_HEAD
    First, rewinding head to replay your work on top of it...
    Applying: a
    Using index info to reconstruct a base tree...
    M	a
    Falling back to patching base and 3-way merge...
    Auto-merging a
    CONFLICT (content): Merge conflict in a
    Failed to merge in the changes.
    Patch failed at 0001 a
    The copy of the patch that failed is found in:
       /private/tmp/a/.git/rebase-apply/patch

>   When you have resolved this problem, run "git rebase --continue".
>   If you prefer to skip this patch, run "git rebase --skip" instead.
>   To check out the original branch and stop rebasing, run "git rebase
>   --abort".

-David