Google Summer of Code '19: Add functionality to store an unresolved merge-state

Navaneeth Suresh navaneeths1998 at gmail.com
Wed May 15 14:28:59 EDT 2019


On Wed, 15 May, 2019, 10:26 PM Pulkit Goyal, <7895pulkit at gmail.com> wrote:

>
>
> On Wed, May 15, 2019 at 7:53 PM Martin von Zweigbergk via Mercurial-devel <
> mercurial-devel at mercurial-scm.org> wrote:
>
>>
>>
>> *From: *Navaneeth Suresh <navaneeths1998 at gmail.com>
>> *Date: *Wed, May 15, 2019 at 5:13 AM
>> *To: *Pierre-Yves David
>> *Cc: *mercurial-devel
>>
>> On Tue, May 14, 2019 at 5:51 PM Pierre-Yves David <
>>> pierre-yves.david at ens-lyon.org> wrote:
>>>
>>>>
>>>>
>>>> On 5/12/19 8:31 PM, Navaneeth Suresh wrote:
>>>> > Hello everyone,
>>>> >
>>>> > I am Navaneeth Suresh, one of the GSoC '19 students with Mercurial. I
>>>> > wanted to discuss my project on adding functionality to store an
>>>> > unresolved merge-state[1]
>>>> > <
>>>> https://www.mercurial-scm.org/wiki/SummerOfCode/Ideas2019#Add_functionality_to_store_an_unresolved_merge-state> with
>>>>
>>>> > the community. Having gone through past mailing list archives on
>>>> similar
>>>> > issues, I got some ideas on the implementation of the project.
>>>> However,
>>>> > there can be other alternatives and I might encounter some issues
>>>> which
>>>> > I might not aware of. So, I'm sharing my idea of implementation.
>>>> >
>>>> > As said by @marmoute, we are storing only one active unresolved
>>>> > merge-state.
>>>>
>>>> Yes, the active merge state exists in .hg/merge/. It is used for the
>>>> operation the triggered a merge (hg merge, hg rebase, etc) and will
>>>> exist until the merge is concluded or aborted.
>>>>
>>>> As far as I understand your project, is to offer a third alternative:
>>>> delaying the merge resolution until later. Right ?
>>>>
>>>
>>> Yes. For example, if a user wants to fix an urgent bug without losing
>>> their partly done enormous conflict resolution, this project will help them
>>> to store the conflicts and resume the resolution after fixing the bug. In
>>> the current scenario, they are only allowed to either fully discard or
>>> complete the partly done resolution to perform a new commit.
>>>
>>>
>>>>
>>>> How do you see the final user experience? What is the workflow to delay
>>>> and later conclude/abort a merge? (note: there are some UX details from
>>>> you later in this email, but it probably worth being explained
>>>> independently).
>>>>
>>>
>>> From the UI point of view, it appeared to me as shelving with conflicts.
>>>
>>
>> Good idea.
>>
>>
>>> I thought of introducing two commands `hg store-conflicts` and `hg
>>> restore-conflicts`.
>>>
>>
>> Or even reuse `hg shelve` and `hg unshelve`?
>>
>
> I agree. `hg shelve --unresolved`.
>

This project also involves publishing the conflict changesets so that other
users can also help in the resolution. This will violate the default
behaviour of shelve changesets if it comes under shelve. That's why I left
that idea on shelve.


> (I am still in-process of writing a reply to whole proposal)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190515/c2116154/attachment.html>


More information about the Mercurial-devel mailing list