[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git transition workflow

From: David Caldwell
Subject: Re: Git transition workflow
Date: Wed, 13 Aug 2014 11:15:40 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 8/13/14 7:16 AM, Sergey Organov wrote:
> Stefan Monnier <address@hidden> 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:

>   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".


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]