On Sun, Feb 23, 2014 at 6:57 AM, Thomas Rast <t...@thomasrast.ch> wrote:
> Eric Sunshine <sunsh...@sunshineco.com> writes:
>
>> On Sat, Feb 22, 2014 at 4:17 AM, Thomas Rast <t...@thomasrast.ch> wrote:
>>> Using the new no_worktree flag from the previous commit, we can teach
>>> merge-recursive to leave the worktree untouched.  Expose this with a
>>> new strategy option so that scripts can use it.
>>>
>>> Signed-off-by: Junio C Hamano <gits...@pobox.com>
>>> ---
>>> diff --git a/Documentation/merge-strategies.txt 
>>> b/Documentation/merge-strategies.txt
>>> index fb6e593..2934e99 100644
>>> --- a/Documentation/merge-strategies.txt
>>> +++ b/Documentation/merge-strategies.txt
>>> @@ -92,6 +92,10 @@ subtree[=<path>];;
>>>         is prefixed (or stripped from the beginning) to make the shape of
>>>         two trees to match.
>>>
>>> +index-only;;
>>
>> s/;;/::/
>
> I think ;; is actually correct: this continues the sub-list of options
> to the recursive strategy.  The :: level lists the available strategies.

Make sense. Thanks for the explanation.

>>> +       Write the merge result only to the index; do not touch the
>>> +       worktree.
>>> +
>>>  octopus::
>>>         This resolves cases with more than two heads, but refuses to do
>>>         a complex merge that needs manual resolution.  It is
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Thomas Rast
> t...@thomasrast.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to